Prev: Using Boost.Spirit in production code
Next: Arguement against NULLing a pointer after delete?
From: Martin B. on 11 Nov 2009 19:09
Le Chaud Lapin wrote:
> On Nov 11, 1:31 pm, Michael Aaron Safyan <michaelsaf...(a)gmail.com>
> wrote:
>> 1.) A visual environment is very difficult to automate, whereas
>> commandline invocations are easy to automate.
>> 2.) Commandline invocations allow your program to be built quickly.
>> 3.) Commandline invocations allow your program to be built
>> automatically.
>
> IMO, this is a common misconception regarding IDE's.
>
> I got my start in VMS, then Unix, then Windows, and have been using
> Visual Studio since the days of Quick C, and whatever can be done with
> using command line, scripts, whatever, I can do that, plus more, with
> the IDE.
>
> I have seen that people who make this IDE/command-line argument
> typically have not put as much time into the IDE as they have into the
> command line [I am not saying you are necessarily one of those people,
> Michael]. In any case, after having experienced both methods for at
> least 7 years each, there is no way I will revert to using a command
> line to manage 50,000-line projects.
>

I would never use a commandline either, unless forced to. But one might
note that for Visual C++ the IDE basically *can* do everything, but
sometimes (seldom!) this involves manually calling some commandline
script or whatnot. And automating a build can be a pain for some corner
cases -- although less pain than if I'd started out with no IDE whatsoever.

> For example, I am on the ICU mailing list (http://site.icu-
> project.org/), [essentially a String library], and their download
> package can be built using both the IDE and the command line. The IDE
> build method is simple: there is one file. You load this file into the
> IDE, then hit the button labeled "BUILD", and sit back and watch. The
> command line system, OTOH, causes world-class programmers from
> prominent organizations to issue on average 2-3 emails per day on the
> support list struggling to get the large mess of make files and build
> scripts to work. (...)
>

This sounds rather like the ICU project has a focus on building it via
the GUI and the commandline build is a second class citizen.
I wouldn't generalize.

My experiences only go so far as libXML2 and boost, but both libraries
are very easy to build via the commandline.
My experience is that when one is new, the approach is often slightly
different:
IDE:
(1) Load project. (2) Try to build. (3) Check errors. (4) Read docs
about configuration. (5) Build again.
CLI:
(1) Start favourite console. (2) Read docs about configuration. (3) Try
to build. (4) Check errors. (5) Build again.

> To the OP:
>
> The Visual Studio 2008 Express C++ compiler is state of the art.
>

Agreed.

> (...)
>
> As far as GUI programming goes..I hope you will not be lured into
> thinking that there is a panacea in Qt and other kits. What most of
> these "cross-platform" kits provide is a (sometimes thin) wrapper
> around native OS GUI API. In many cases, you not only have to learn
> the wrapper, but when you get stuck, you still need to know a bit
> about what's going on under the hood. (...)

Nothing's a cure-all. However, these toolkits make a kick-start much
easier and they offer great tools. Just because advanced stuff needs
advanced knowledge is no reason to forgo these toolkits.

> Since you will be doing neural networks, you undoubtely want to draw
> your own nets. In that case, I think your ideal combination will the
> the compiler above, plus a no-nonsense C++ graphics library that
> already comes with Windows, GDI+. (...) You will have a slight
> learning curve just to get the window up on the screen (...)

[Quote MSDN]
About GDI+
Microsoft Windows GDI+ is the portion of the Windows XP operating system
or Windows Server 2003 operating system that provides two-dimensional
vector graphics, imaging, and typography.
[/Quote]

GDI+ is a drawing library and not a graphics library.
It isn't about getting a window up to the screen, so one should still
use a decent window library.


br,
Martin

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Le Chaud Lapin on 12 Nov 2009 01:37
On Nov 12, 6:09 am, "Martin B." <0xCDCDC...(a)gmx.at> wrote:
> Le Chaud Lapin wrote:
> > For example, I am on the ICU mailing list
> > (http://site.icu-project.org/), [essentially a String library],
> > and their download
> > package can be built using both the IDE and the command line.
>
> This sounds rather like the ICU project has a focus on building it via
> the GUI and the commandline build is a second class citizen.
> I wouldn't generalize.

Well, for ICU, actually, it is the opposite: it is evident that from
the code structure that the authors love scripting/etc. The IDE one-
click build thing was put in as an after-thought. And even then, they
use the IDE in some cases as a glorified script driver, preepting the
IDE from doing what it does best: managing dependencies.
[Incidentally, this morning, I received 3 new posts from the ICU
support list about people having problems with such build scripts.]

> My experiences only go so far as libXML2 and boost, but both libraries
> are very easy to build via the commandline.
> My experience is that when one is new, the approach is often slightly
> different:
> IDE:
> (1) Load project. (2) Try to build. (3) Check errors. (4) Read docs
> about configuration. (5) Build again.
> CLI:
> (1) Start favourite console. (2) Read docs about configuration. (3) Try
> to build. (4) Check errors. (5) Build again.

Well, technically, if the author did what s/he is supposed to have
done, then there should be no errors, so one has to go with the
assumption that the build is error free. IMO, generating an error-free
build is more likely using the IDE than with the tedium of CLI.

Please note that I am not saying that the programmer should be
oblivious to sed/awk/make/randlib/etc...or their equivalents on
Windows. They should have an understanding of these things,
dependencies, the linker, etc. But, .after. these understandings, they
could move to the IDE.

An analogy might be C++ versus assembly. I believe that every C++
programmer should be able to write "Hello, World.", in assembly code,
of the kind that might be generated from a C++ compiler. After they do
this, then they can program in a macro-language (C++), and for
situations were some assembly is required, they augment their C++ with
assembly. They get the best of both worlds: micro understanding with
macro control and the option of reverting to micro control when
necessary.

> [Quote MSDN]
> About GDI+
> Microsoft Windows GDI+ is the portion of the Windows XP operating system
> or Windows Server 2003 operating system that provides two-dimensional
> vector graphics, imaging, and typography.
> [/Quote]
>
> GDI+ is a drawing library and not a graphics library.
> It isn't about getting a window up to the screen, so one should still
> use a decent window library.

I agree, but every one that I have tried left me sighing.

The exception might be Mirek Filder's Ultimate C++, which I have not
used, but if I were to try one, I would try it first:

http://www.ultimatepp.org/

-Le Chaud Lapin-


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: news on 12 Nov 2009 01:39
On 11.11.2009 7:19, Jay wrote:
> I am not a programmer, but have a technical background, and studied
> programming quite a few years back, including some classes in C and C+
> +. I am seeking to get back up to speed in C++ on a hobby basis, so
> I'm trying to figure out which compiler to get now. A search on the
> web reveals lots of compilers, but it's hard to know which ones meet
> my needs. Hoping someone can help. My requirements:
>
> 1. Free or cheap.
>
> 2. Compiler for Windows. Currently running XP, may upgrade to Win7
> at some point.
>
> 3. Definitely want an integrated GUI development environment, not
> command line.
>
> 4. Biggest problem I had back in the past was creating a GUI. I
> tried to learn MFC, it was a total bear. Ideally I'd like something
> that makes GUI creation with C++ as intuitive and easy as with Visual
> Basic, and failing that, something like Java (which I found
> challenging, but doable). I want to be able to focus on developing
> the background logic (I'm planning to do some simple neural network
> and other AI programming, for example), I don't want to be messing for
> hours trying to create a simple dialog box or other user interface.
> The development environment should make that part easy, and hide the
> MFC complexities (or whatever has replaced MFC these days).
>
> Thanks in advance for all replies.
>

No one has yet to tell you about Borland's Turbo C++ (C++ Builder)

http://www.turboexplorer.com/

It should be very easy to create GUI with this, and the logic too, all
in C++ language. And it is FREE, as in free beer.

--
Q: How many Bell Labs Vice Presidents does it take to change a light bulb?
A: That's proprietary information. Answer available from AT&T on payment
of license fee (binary only).

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Paul Bibbings on 12 Nov 2009 09:19
news wrote:
> No one has yet to tell you about Borland's Turbo C++ (C++ Builder)
>
> http://www.turboexplorer.com/
>
> It should be very easy to create GUI with this, and the logic too, all
> in C++ language. And it is FREE, as in free beer.

If you are indeed talking about one of the C++ Builder editions, rather than,
say, some very old archive version of something like the BCC55 command line
compiler, then the 'Borland' offerings are *not* free, as in "You want beer? You
pay for your beer then." A free trial, however, is available.

Regards

Paul Bibbings

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: news on 12 Nov 2009 13:59
On 13.11.2009 4:19, Paul Bibbings wrote:
> news wrote:
>> No one has yet to tell you about Borland's Turbo C++ (C++ Builder)
>>
>> http://www.turboexplorer.com/
>>
>> It should be very easy to create GUI with this, and the logic too, all
>> in C++ language. And it is FREE, as in free beer.
>
> If you are indeed talking about one of the C++ Builder editions, rather than,
> say, some very old archive version of something like the BCC55 command line
> compiler, then the 'Borland' offerings are *not* free, as in "You want beer? You
> pay for your beer then." A free trial, however, is available.
>

Ok;)

It's not Borland now, it's Embarcadero Technologies. Same stuff, anyway.
Borland decided to drop her development tools division.

--
Whenever you find that you are on the side of the majority, it is time
to reform.
-- Mark Twain

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Using Boost.Spirit in production code
Next: Arguement against NULLing a pointer after delete?