Seeking recommendation on free or cheap C++ compiler
Jay
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.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Martin B.
Personally - if you're going Windows only - I'd use Visual Studio
Express, which is free. (The express edition doesn't include MFC anyway).
The GUI stuff would be tacked on here though, but you'd be free to
choose. (GTK+, Qt, wxWidgets, ...)
In my opinion VS offers the best IDE with the best integrated debugger.
You might also consider going with Qt only. Nokia offers a pretty nice
IDE (QtCreator) and after getting used to Qt it seems to be really
simple to throw together some GUI.
The coding part is also very nice, although it shows that this is still
a 1.x product.
Then there's Eclipse + CDT which I have tried and which isn't so bad but
if you're Windows only I really can't see the point as VS seems
better/easier/more stable in most aspects.
If you want to try wxWidgets for GUI Code::Blocks might be worth a look
as it seems to be geared towards that.
br,
Martin
eca
> [...] 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.
You might want to try the following:
IDEs:
a) MS Visual Studio 2005 or 2008 express edition, includes one of
the best IDE (IMHO) and MS C++ compiler.
http://www.microsoft.com/express/vc/
b) Qt SDK. Includes a nice IDE, MingW g++ and Qt libraries. IMHO,
ideal for a quick start.
http://qt.nokia.com/products
c) Netbeans with C++ plugin. This is the one I prefer for
cross-platform development
http://netbeans.org/
d) Eclipse IDE for C/C++ Developers, also cross-platform
http://www.eclipse.org/
Compilers:
Unless you choose Visual Studio express, which includes MS C++
compiler,
g++ is the one. On Windows I would suggest CygWin or MingW flavours
http://www.cygwin.com/
http://www.mingw.org/
GUI:
I would suggest Qt by Nokia (formerly, Trolltech) open source edition.
http://qt.nokia.com/
Many also like wxWidgets:
http://www.wxwidgets.org/
My 2c.
eca
Phil Meier
On Nov 11, 6:19 am, Jay <greengrass...@yahoo.com> wrote:
> [ Seehttp://www.gotw.ca/resources/clcm.htmfor info about ]
> [ comp.lang.c++.moderated. First time posters: Do this! ]
You could use Visual Studio Express - use C++ for your algorithms and
use C# for the GUI.
BR Phil
Michael Aaron Safyan
> 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.
The GNU Compiler Collection (GCC) is free and the de-facto standard
for compilers. (Alternative compilers such as LLVM and xlc++, as a
general rule, provide a compatible front-end that can accept the same
options as GCC. The Visual Studio compiler is the rare exception, not
the rule).
>
> 2. Compiler for Windows. Currently running XP, may upgrade to Win7
> at some point.
>
Cygwin is a good way of installing GCC. The Win7 version is currently
in beta. I am not sure of how stable it is.
> 3. Definitely want an integrated GUI development environment, not
> command line.
Any compiler is going to be commandline. Sorry. What you are looking
for is not a compiler, but an Integrated Development Environment (IDE)
which provides you with an editor and will invoke the (commandline)
compiler for you. Even though YOU like something visual, you should
start becoming familiar with non-visual setup/configuration, because:
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.
4.) As a corollary to #3, commandline invocations make it simple to
perform CONTINUOUS INTEGRATION TESTING, by enabling the server on
which your source code repository is hosted to attempt to build the
project and use the results (fail or success) to determine whether it
should accept source code changes.
5.) As a corollary to #4, commandline invocations make it possible to
create automatic source code-based installers that can automatically
fetch your source code archive, compile the source code on the target
machine using the machine's compiler, and then install the resulting
binary.
I strongly recommend that you use CMake for building your project. The
CMake build system, though it requires a textual specification, allows
you to generate various different types of projects in a cross-
platform manner based on your specification. The CMake build system
can generate Makefiles (which are purely commandline) but can also
generate Visual Studio .NET "Solution" project files, which allow you
to edit the project visually.
Failing CMake (I suspect you are quite averse to the textual route,
even if it is better for you... and everyone else), I recommend that
you use the QtCreator IDE, which comes with the Qt Framework. The
QtCreator IDE is a cross-platform integrated development environment.
Not only will it allow you to edit your code visually, but it will
also allow you to drag-and-drop UI components. Along with the Qt
Framework, it provides GUI functionality. (NOTE: You can use the Qt
Framework with CMake... in fact, CMake includes several commands
specifically for the use of the Qt Framework).
>
> 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).
This one is a no-brainer. Use the Qt Framework. It is cross-platform
(works on Windows, Mac OS X, and Linux, and it even has an embedded
version for the Nokia S60 and other devices). The Qt Framework may be
downloaded from:
You might like to see my recommended C++ development environment setup
guide:
http://sites.google.com/site/michaelsafyan/coding/resources/how-to-guides/development-environment-setup/cpp
The setup guide above gives directions for installing GCC, Qt, Make,
CMake, Pkg-config, Log4Cxx, and UnitTest++. With these, it is possible
to use the C++ Project Template on Google Code:
http://code.google.com/p/cpp-project-template/
{ Please do not quote irrelevant material as below. -mod }
>
> Thanks in advance for all replies.
>
> --
> [ Seehttp://www.gotw.ca/resources/clcm.htmfor info about ]
tohava
gcc. VC++ express.
>
> 2. Compiler for Windows. Currently running XP, may upgrade to Win7
> at some point.
gcc has windows versions.
>
> 3. Definitely want an integrated GUI development environment, not
> command line.
dev-c++.
>
> 4. Biggest problem <snipped>
Tough one... If you use gcc i'd recommend trying Qt, which I believe
has a tool for creating GUIs visually. I think VC++ express should
also help with this.
Martin B.
> On Nov 10, 11:19 pm, Jay <greengrass...@yahoo.com> 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.
>
> The GNU Compiler Collection (GCC) is free and the de-facto standard
> for compilers. (Alternative compilers such as LLVM and xlc++, as a
> general rule, provide a compatible front-end that can accept the same
> options as GCC. The Visual Studio compiler is the rare exception, not
> the rule).
>
Hmm ... it would be interesting where and on what you work to claim such
a thing. (It would also be nice to add some references to such claims.)
I would have said the opposite: Visual Studio is the default for
Windows-Only SW which seems to be sort of a default for much desktop
software.
>> 2. Compiler for Windows. Currently running XP, may upgrade to Win7
>> at some point.
>>
>
> Cygwin is a good way of installing GCC. The Win7 version is currently
> in beta. I am not sure of how stable it is.
>
Hmm ... what benefit does the Cygwin environment add to GCC vs. MinGW ??
cheers,
Martin
Andrew
> 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.
gcc (aka g++). It is free (as in freedom) software, which is also free
(as in beer).
>
> 2. Compiler for Windows. Currently running XP, may upgrade to Win7
> at some point.
gcc is available for windoze via cygwin. There is also minGW which
compiles down to native apps without needing something like the cygwin
DLL.
>
> 3. Definitely want an integrated GUI development environment, not
> command line.
Eclipse is a great IDE that has a C++ plugin. There is also a version
called Wascana on sourceforge that has set things up for use with the
gcc toolchain. I reckon this will suit you just fine.
>
> 4. Biggest problem I had back in the past was creating a GUI. I
> tried to learn MFC, it was a total bear.
Why am I not suprised.
> Ideally I'd like something
> that makes GUI creation with C++ as intuitive and easy as with Visual
> Basic
Try looking at wxWidgets. It also happens to be cross-platform. If you
fancy something easier (but not quite as good) you can try FLTK (Fast,
Light ToolKit). It comes with a GUI builder called 'fluid'.
Regards,
Andrew Marlow
Nick Hounsome
IMHO C++ language is not a language to go for "on a hobby basis" at
least in part because of the GUI issue.
If you want something C++ like (very loosely) I suggest you go for C#
and the free "express" IDE from MS
If you want something more interactive I suggest one of the scripting
languages as supplied by ActiveState (Tcl, Perl, Python)
If you realy want to play C++ I suggest that you stick to command line
apps.
Maybe try http://www.bloodshed.net/download.html for an IDE or the MS
express version.
Under no circumstances should you attempt to use MFC. Qt might be best
for you.
Le Chaud Lapin
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.
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. The build itself becomes a multi-week effort. One
poster recently claimed 72,000 error using the build scripts.
Naturally, there is always some "workaround", in the form of yet more
scripting, to fix what should never have been broken in the first
place.
To the OP:
The Visual Studio 2008 Express C++ compiler is state of the art.
Think of it as a high-end BMW with nice-to-have premium features like
independent climate control, high-watt audio amp, and heated-back-
massager removed. That's what VS Expres is: less than what you would
get as a paying customer, but still a ~disturbingly~ nice vehicle.
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. This is partially a result of
the inextricable awkwardness of underlying GUI architecture on
Windows. Note that the SDK for Qt for Windows is 178MB. The one for
Mac is 0.5GB.
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+. IMO, the author of this libary did a
very good job of thinking first, then doing, whereas some of the other
frameworks seem to have grown organically. You will have a slight
learning curve just to get the window up on the screen and process
messages, but once you have done that, you can quickly move to the
part that matters: GDI+.
References:
http://www.microsoft.com/exPress/
http://qt.nokia.com/downloads
http://msdn.microsoft.com/en-us/library/ms534427(VS.85).aspx
-Le Chaud Lapin-
Martin B.
> On Nov 11, 1:31 pm, Michael Aaron Safyan <michaelsaf...@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
Le Chaud Lapin
> Le Chaud Lapin wrote:
> > For example, I am on the ICU mailing list
> > and their download
> > package can be built using both the IDE and the command line.
>
> 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:
-Le Chaud Lapin-
news
No one has yet to tell you about Borland's Turbo C++ (C++ Builder)
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).
Paul Bibbings
> 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
--
news
> 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
Jorgen Grahn
...
> Even though YOU like something visual, you should
> start becoming familiar with non-visual setup/configuration, because:
>
> 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.
> 4.) As a corollary to #3, commandline invocations make it simple to
> perform CONTINUOUS INTEGRATION TESTING, by enabling the server on
> which your source code repository is hosted to attempt to build the
> project and use the results (fail or success) to determine whether it
> should accept source code changes.
> 5.) As a corollary to #4, commandline invocations make it possible to
> create automatic source code-based installers that can automatically
> fetch your source code archive, compile the source code on the target
> machine using the machine's compiler, and then install the resulting
> binary.
It should be noted here that you don't have to believe in CONTINUOUS
INTEGRATION TESTING (what's up with those capital letters?) to prefer
the command line. I personally see no reason that I should let a
machine prevent me from commiting my changes -- if I want it that way
I just say 'make check && cvs ci -m "something"'.
> I strongly recommend that you use CMake for building your project. The
> CMake build system, though it requires a textual specification, allows
> you to generate various different types of projects in a cross-
> platform manner based on your specification. [...]
It should be noted here that people tend to be religious about their
'make' utilities. Personally, I've never used CMake -- all decent
software I've encountered has used plain Gnu Make (often behind
automake). I'm religious about Gnu Make, and I think Michael is about
CMake.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jeff Schwab
Le Chaud Lapin wrote:
> On Nov 11, 1:31 pm, Michael Aaron Safyan <michaelsaf...@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.
That's patently untrue. I really don't think you realize just how
flexible the command-line is, no matter how long or intensively you
claim to have used it. For example, when I've performed a sequence of
actions in an IDE, there is no backscroll buffer for me to copy and
paste into a script or an email. There is no way to store a typescript,
much less to edit the typescript in the same environment from which it
was created; the closest you can come is some kind of effectively
immutable screen-cast. The IDE will not run in the serial console I use
every day, and using it over an ssh connection is either impossible or
painfully slow, depending on the IDE, the bandwidth of the connection,
and the nature of the workstation.
It's also worth noting that not all command lines are created equal. I
recently started training some Windows developers to start using Linux,
and there are some deeply ingrained misconceptions to overcome; for
example, a lot of Windows developers see a terminal emulator, and
immediately assume it has no more power than a Windows "DOS box." I
notice, too, that MS seems to be making a concerted effort to kill even
their own CLI; for example, the MS terminal emulator no longer supports
full-screen mode in Vista, and blatantly lies to the user: "This system
does not support full screen mode."
Martin B.
We might note that IDE is a common abbreviation of Integrated
Development Environment. In theory this only implies that all the
components needed to develop software in C++ are well and truly
integrated. (Editor Compiler Linker Debugger ...)
Integration - for example - means that I change a source line and then
hit one button that automagically saves the file, compiles+links the
application and runs it under the debugger.
This means a tremendous productivity increase for the developer and
lower hurdles for newbies as the IDE hides the details for them.
Of course the IDE will invoke some commands under the hood and sometimes
we might have to tweak or analyse them - however, this should be the
exception.
To sum up my opinion:
The C++ developer that is afraid of the CLI is a bad C++ programmer but
the C++ developer that doesn't use an IDE because "CLI rules" is also
wrong, because he misses a great productivity boost.
cheers,
Martin
Le Chaud Lapin
> > 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.
>
> That's patently untrue. I really don't think you realize just how
> flexible the command-line is, no matter how long or intensively you
> claim to have used it. For example, when I've performed a sequence of
> actions in an IDE, there is no backscroll buffer for me to copy and
> paste into a script or an email. There is no way to store a typescript,
> much less to edit the typescript in the same environment from which it
> was created; the closest you can come is some kind of effectively
> immutable screen-cast. The IDE will not run in the serial console I use
> every day, and using it over an ssh connection is either impossible or
> painfully slow, depending on the IDE, the bandwidth of the connection,
> and the nature of the workstation.
Given that the IDE can be invoked from the command line, and that the
IDE can run any command line script, it is logical to conclude that
the feature set of the IDE is a superset of the features set of the
command line.
Therefore, whatever can be done using the command line can be done
with the IDE, but the reverse is not true.
At that point, it becomes a matter of preference of the user:
1. Some users will prefer the IDE, and never the command line.
2. Some users will prefer the command line, and never the IDE.
3. Some users will lean heavily toward IDE, using command line
occasionally.
4. Some users will lean heavily toward command line, using IDE
occasionally.
In absence of the IDE, three of these possibilities are immediately
eliminated.
In absence of the command line, none of them are eliminated, because
the IDE always includes the command line.
-Le Chaud Lapin-