Compiler for C++ programming

[Jerome]

Which compiler would be good to learn C++ template programming, on
windows platform.
I have access to VC++, but I have read that VC++ does not provide the
STL library as per the C++ STL standards.
If the above is true then which would be the ideal compiler to use.

 

[Linlin Yan]

Which compiler would be good to learn C++ template programming, on
windows platform.
I have access to VC++, but I have read that VC++ does not provide the
STL library as per the C++ STL standards.
If the above is true then which would be the ideal compiler to use.

GCC: http://gcc.gnu.org/

 

[Richard Herring]

In message

Which compiler would be good to learn C++ template programming, on
windows platform.
I have access to VC++, but I have read that VC++ does not provide the
STL library as per the C++ STL standards.
If the above is true

The above may not be true. VC++ 6 was notoriously non-compliant in many
respects, but has long been superseded by versions which are much closer
to the standard.

 

[robertwessel2]

In message


The above may not be true. VC++ 6 was notoriously non-compliant in many
respects, but has long been superseded by versions which are much closer
to the standard.

The (now) ancient VC6 (and several other compilers) got caught in the
very rapidly evolving C++ standard in 1998, especially as regards
templates. IOW, VC6 largely implemented the draft standard, which
then changed. Most of the big VC6 issues are related to that. MS in
general, does not update language features/syntax within a version
(which allows people to continue to compile their code unchanged with
VC6), but put most of the things right in the next release (VC++ .NET
2002).

But to the OP: on Windows, use VC. There's even a free version.

 

[James Kanze]

Which compiler would be good to learn C++ template
programming, on windows platform.
I have access to VC++, but I have read that VC++ does not
provide the STL library as per the C++ STL standards.

That's complete bullshit. The standard library of VC++ is
probably the best and most complete there is---only g++ is in
any way comparable. VC++ is also one of the best C++ compilers
around---only the EDG front ends are better. If you're working
under Windows, there's absolutely no reason to use anything
else. (Except, of course, for portability checks. It's always
better to compile code with two or more compilers, just to be
sure.)

 

[Christopher Dearlove]

In message


The above may not be true. VC++ 6 was notoriously non-compliant in many
respects, but has long been superseded by versions which are much closer
to the standard.

And bad as VC++6 was/is, it has most of the STL, although it's weak on
some corners thereof. It's real limitations are on template member functions
and on scope of variables declared in for statements that make you write
VC++6 specific code in these areas. And I have pushed it into compiler
internal errors in some template use areas.

 

[Balog Pal]

Which compiler would be good to learn C++ template programming, on
windows platform.
I have access to VC++, but I have read that VC++ does not provide the
STL library as per the C++ STL standards.

Guess that was about 6.0 and 7.0 back ~2000, some time passed since...

 

[Rui Maciel]

Which compiler would be good to learn C++ template programming, on
windows platform.
I have access to VC++, but I have read that VC++ does not provide the
STL library as per the C++ STL standards.
If the above is true then which would be the ideal compiler to use.

GCC is your friend, as it's not only (arguably) the best C++ compiler out there but it's also free/open
source software. There are also a hefty number of free/open source IDEs for windows that support GCC, such as
Dev-C++ and Code::Blocks.


Rui Maciel

 

[Jerry Coffin]

That's complete bullshit. The standard library of VC++ is
probably the best and most complete there is---only g++ is in
any way comparable. VC++ is also one of the best C++ compilers
around---only the EDG front ends are better.

I'd agree with that much.

If you're working
under Windows, there's absolutely no reason to use anything
else. (Except, of course, for portability checks. It's always
better to compile code with two or more compilers, just to be
sure.)

Even when portability isn't the issue, I find Comeau C++ to provide
excellent diagnostics, especially for templates. When you can't quite
figure out why something won't compile, the error message from Comeau
is often enough more specific that when VC++ left you scratching your
head, Comeau tells you exactly what to do.

 

[Bo Persson]

GCC is your friend, as it's not only (arguably) the best C++
compiler out there but it's also free/open source software. There
are also a hefty number of free/open source IDEs for windows that
support GCC, such as Dev-C++ and Code::Blocks.

I don't exactly see an advantage in having an open source compiler,
when trying to learn template programming.

The VC++ Express Edition is free, like in free beer. An excellent
compiler if you target Windows.

http://www.microsoft.com/express/vc/


Bo Persson

 

[Jerry Coffin]

GCC is your friend, as it's not only (arguably) the best C++ compiler
out there but it's also free/open source software.

There aren't very many C++ compilers around, at least that anybodys
really trying to keep current. The obvious candidates on Windows are
MS, Intel, Comeau, and g++. At least for conformance, Comeau is
pretty clearly the best, though Intel is a close second. The best you
could even hope to claim for g++ is that while it's in last place,
it's not really _much_ worse than VC++.

OTOH, unless you're dealing with really obscure code, they difference
between the best and the worst is pretty minimal, so g++ is still
perfectly usable.

By other measures, g++ generally does pretty poorly as well. You can
generally figure that executables it produces will be at least twice
the size of those from VC++, and often three or four times as big.
The code can be competitive in terms of speed, but again, that
usually translates to "last place, but fairly close to the others".
Of course, that depends somewhat on the version of the compiler
involved as well -- they overhauled the whole optimizer section for
(IIRC) version 4. It now has what's supposed to be a very general
framework for all kinds of optimization code, but (at least IME)
still doesn't produce as fast of code as the older compilers did.

There are also a hefty number of free/open source IDEs for windows
that support GCC, such as Dev-C++ and Code::Blocks.

I'd have a hard time recommending either of those.

For Code::Blocks, the installation is rather problematic -- not
terrible, but (basically) unless you've installed gcc exactly where
it expects, it probably won't find it -- but it'll still treat gcc as
the default compiler, so attempts at compiling will do nothing -- not
even show an error message to warn you that it didn't work at all. It
also seems to pretty much require that you've successfully installed
the compiler first, and that can be non-trivial. On the good side, at
least once you've gotten it installed and working, it does work
reasonably well.

Dev-C++ has rather different problems. If you get it with a compiler,
you get g++ 3.4.2 -- roughly five years old, and no longer
competitive. The look and feel of the IDE appear to be based on
Borland's -- from about 20 years ago. Calling them dated and clunky
is a compliment. The editor is downright primitive, without even so
much as the ability to search for a regular expression. When I was
writing Fortran IV on a Control Data mainframe, I had an editor more
capable than this...

 

[James Kanze]

I'd agree with that much.

It does have one major defect: the code it generates doesn't
work on a Sparc, under Solaris, which until recently, was my
major platform. I really do wish it (or something equally as
good) were available for Unix platforms. (Not that it really
matters to me any more. Starting in a week from now, I'll be
working in a purely Microsoft environment.)

Even when portability isn't the issue, I find Comeau C++ to
provide excellent diagnostics, especially for templates. When
you can't quite figure out why something won't compile, the
error message from Comeau is often enough more specific that
when VC++ left you scratching your head, Comeau tells you
exactly what to do.

I hesitated about mentionning Comeau. For various reasons, I've
not used it enough to judge myself, but everything I've seen or
heard about it has been highly positive. And everyone I know
who has used it rates it as best.

 

[James Kanze]

I seem to remember the "fix" for that looked something like:

#if defined(_MSC_VER) && _MSC_VER <= 1200
#define for if(0); else for // VC++6 scoping bugfix
#endif

There was never any need for any fix; you just didn't use the
variable after the for. The only way this was ever a problem
was that it allowed some legacy code to compile, although it
wasn't legal.

 

[James Kanze]

There aren't very many C++ compilers around, at least that
anybodys really trying to keep current. The obvious candidates
on Windows are MS, Intel, Comeau, and g++. At least for
conformance, Comeau is pretty clearly the best, though Intel
is a close second. The best you could even hope to claim for
g++ is that while it's in last place, it's not really _much_
worse than VC++.

OTOH, unless you're dealing with really obscure code, they
difference between the best and the worst is pretty minimal,
so g++ is still perfectly usable.

Obscure is in the eyes of the beholder. VC++ supports Unicode
in symbols, g++ doesn't. Comeau, and I think Intel, support
export, which neither VC++ nor g++ does; if you're doing any
serious programming with templates, that could be an important
plus.

By other measures, g++ generally does pretty poorly as well.
You can generally figure that executables it produces will be
at least twice the size of those from VC++, and often three or
four times as big. The code can be competitive in terms of
speed, but again, that usually translates to "last place, but
fairly close to the others". Of course, that depends somewhat
on the version of the compiler involved as well -- they
overhauled the whole optimizer section for (IIRC) version 4.
It now has what's supposed to be a very general framework for
all kinds of optimization code, but (at least IME) still
doesn't produce as fast of code as the older compilers did.

But it's still fast enough for most applications. On Sparc, any
time we weren't bound by third party libraries, we'd use g++,
rather than Sun CC, despite the fact that g++ generated code was
slower.

I'd have a hard time recommending either of those.

For Code::Blocks, the installation is rather problematic --
not terrible, but (basically) unless you've installed gcc
exactly where it expects, it probably won't find it -- but
it'll still treat gcc as the default compiler, so attempts at
compiling will do nothing -- not even show an error message to
warn you that it didn't work at all. It also seems to pretty
much require that you've successfully installed the compiler
first, and that can be non-trivial. On the good side, at least
once you've gotten it installed and working, it does work
reasonably well.

Dev-C++ has rather different problems. If you get it with a
compiler, you get g++ 3.4.2 -- roughly five years old, and no
longer competitive. The look and feel of the IDE appear to be
based on Borland's -- from about 20 years ago. Calling them
dated and clunky is a compliment. The editor is downright
primitive, without even so much as the ability to search for a
regular expression. When I was writing Fortran IV on a Control
Data mainframe, I had an editor more capable than this...

Which raises the question: should an IDE even have its own
editor? I use vim pretty much everywhere as my editor, and in
practice, about the only thing I've seen that an IDE brings,
compared with vim and a command interpreter, is context
sensitive help. And the Unix based IDE's that I've used have
always treated the editor as a plug-in component, so that I
could use vim with them as well (and my collegues could use
emacs).

 

[Noah Roberts]

There aren't very many C++ compilers around, at least that anybodys
really trying to keep current. The obvious candidates on Windows are
MS, Intel, Comeau, and g++. At least for conformance, Comeau is
pretty clearly the best, though Intel is a close second. The best you
could even hope to claim for g++ is that while it's in last place,
it's not really _much_ worse than VC++.

Would be interesting to see where you get your data. Personal
experience would dictate that, at least based on standard conformance,
g++ wins hands down over VC++. I've found numerous compiler bugs in
VC++ that simply don't happen with the same code in g++.

For example, VC++ often vomits with a compiler crash when you use
classes defined in function scope. It also doesn't do templated friends
correctly. There's a few other long standing template issues that I
can't immediately remember which I've run into in VC++ but g++ knows how
to handle fine.

It seems to me that any time I "push the boundaries of the standard",
and even when I'm not, VC++ fails long before g++ has any troubles. In
fact I can't think of the last time g++ crashed on me but I got a VC++
crash only a couple months ago (the internal class thing).

 

[Balog Pal]

On Sep 10, 11:37 pm, Jerry Coffin <[email protected]>

[ this group is always worth reading for Jerry... ]

Which raises the question: should an IDE even have its own
editor?

Sure, that's why it is callet *I*DE ;-) but the user-friendliest one would
allow to replace the whole editor, or make it extremely tune-able.

I use vim pretty much everywhere as my editor, and in
practice, about the only thing I've seen that an IDE brings,

Well, you say moving to Win development, If you invest into using VS, I'd be
very interested to read opinion half or one year from now, and how much you
want vim back. (which certainly has a deal of good features in ctags
support, but ways less than possible and good to use...)

compared with vim and a command interpreter, is context
sensitive help.

Which (BAH), worked well in MS stuff perfectly until version 5.0 and sinks
ever since, I wonder if for VS2010 they discover new ways to spoil it even
further. :-(((

It used to find exactly what is needed -- now it takes a year to start,
searches for another two years locally and on several net sources (that can
be restricted to local, but then mine just found nothing anymore...) and
will jump to irrelevant occurances of the word you launched it on, without
any reasonable way to know where you are, and how to get to the rest of the
results...

Guess I as the last mohican to ever use F1 for anything, so no one noticed
the situation.

And the Unix based IDE's that I've used have
always treated the editor as a plug-in component, so that I
could use vim with them as well (and my collegues could use
emacs).

To me the editor itself is pretty arbitrary, the IDE is good for saving much
time in navigation and code reading by showing call/caller graphs, use
locations, definition (it is ways superior to just grep-ing) ,
active/passive #if blocks, certainly at compiling auto-navigating to error
lines in all involved files.

Recently I also discovered the convenience of the 'edit-and-continue'
debugger. Generally I am pretty light on debugging, and in case of a
problem did not need much more than the stop location, or a going some
frames up.
But in a recent work I made an IEEE 11073-20601 protocol implementation,
with all kind of imaginable problems both in sent packets and their
interpretation code -- it saved a big deal of time that I could walk through
a whole case fixing data and code as needed without starting over the
equipment sending new packets with a single spot fixed...

Being able to sensibly organize all the source file windows you work with,
and the various auxillary windows/toolbars is also a good thing.

Too bad that in version 9, approaching 20 years of development VS still has
stupid bugs rendering whole features crap (i.e. 'Task list' picks duplicated
and multiplied items, lacks correct ordering and fails prev/next navigaton;
the code browser still does not show the compiler-created functions, and
does not use compiation info for everything it should; intellisense has no
manual control...) and I recall at least two IDE crashes.

 

[Balog Pal]

There was never any need for any fix; you just didn't use the
variable after the for.

You used another one, that failed.

for(int i=....) {}
for(int i=....) {} // error: i already defined

The only way this was ever a problem
was that it allowed some legacy code to compile, although it
wasn't legal.

That was the root of MS' being stubborn, then around 7.0 there were switches
to tune the for behavior, including 'intelligent' ones that accepted
anything that made sense under any of the rules...

I personally picked up the above #define in 5.0 and stopped bothering what
the compiler does otherwise.

Btw g++ also has a huge list of switches to select standard/dialect and
individual features, including for scoping.

 

[Jerry Coffin]

(e-mail address removed)>, (e-mail address removed)
says...

On Sep 10, 11:37 pm, Jerry Coffin <[email protected]> wrote:

[ ... ]

Obscure is in the eyes of the beholder. VC++ supports Unicode
in symbols, g++ doesn't. Comeau, and I think Intel, support
export, which neither VC++ nor g++ does; if you're doing any
serious programming with templates, that could be an important
plus.

Intel doesn't officially support export, but with the right
(undocumented) flag, it does at least to some degree -- though I've
never tried to put it to a serious test, nor do I know of anybody
else who's done so either.

Support of export depends: if you really want to use export, then
having support for it is obviously _really_ important. I really don't
figure I _can_ use it for real code, so while it's nice to play with
once in a while, it's (at least currently) of no importance to me for
real work.

[ ... g++ producing slower code than the others ]

But it's still fast enough for most applications. On Sparc, any
time we weren't bound by third party libraries, we'd use g++,
rather than Sun CC, despite the fact that g++ generated code was
slower.

Unless Sun CC has improved a lot since the last time I used it, that
doesn't surprise me a bit. Of course, it's rarely a surprise when a
CPU vendor's own compiler produces really good output (in terms of
speed anyway) for their own CPU. Even if they didn't know the CPU
better than just about anybody else, a lot of people choose CPUs
based on benchmarks, so they have a _lot_ of motivation to ensure
they get the best scores possible.

And you're right: the difference in speed is rarely enough to be of
any major consequence -- rarely more than 15-20% or so.

[ ... comments on Code::Blocks and Dev-C++ ]

Which raises the question: should an IDE even have its own
editor?

I have a hard time calling something an Integrated development
environment, if it's really composed of separate tools. At least from
my viewpoint, "integrated" means something that has (at least) a
couple of different functions (e.g. editing and debugging) in the
same environment.

I'd rephrase the question: is the optimum development environment
really integrated, or more of a central manager that gives access to
a number of specialized development tools? I don't think there is a
really good answer to that.

You have pretty much the usual trade offs of a single integrated tool
versus a number of specialized ones: separate tools tend to be
stronger within their specialty, but integrated ones work together
with far fewer "seams".

VS++ (for example) allows you to do minor edits in the middle of
debugging, and it'll integrate the change and continue execution
without losing the context of execution thus far (almost like you
were using an interpreter). This can save a lot of time on minor
mistakes (especially if you spot them before stepping into them).

I use vim pretty much everywhere as my editor, and in
practice, about the only thing I've seen that an IDE brings,
compared with vim and a command interpreter, is context
sensitive help. And the Unix based IDE's that I've used have
always treated the editor as a plug-in component, so that I
could use vim with them as well (and my collegues could use
emacs).

VS++ at least used to have an interface that let other (at least
Windows-based) editors be used with it -- though when I used it, the
integration wasn't as clean as you'd like. In theory, you could do it
very cleanly -- with OLE in-place activation, it can be essentially
unnoticeable, except (of course) for things like additional menu
items appearing when you use them. I'm not sure if VS++ has the hooks
in place to support that though -- my guess is probably not (making
it all seamless takes a fair amount of work).

 

[Jerry Coffin]

That was the root of MS' being stubborn, then around 7.0 there were
switches to tune the for behavior, including 'intelligent' ones
that accepted anything that made sense under any of the rules...

Actually, even in VC++ 6, the compiler could/would/did support the
correct scoping of variables defined in a for loop. The problem was
that it was enabled (only) with the "string ANSI conformance
switch" -- and when you enabled that, it could no longer compile most
of its own headers. I don't think any of them depended on the
incorrect scope of variables defined in a for loop, but that switch
also enforced a number of other standard requirements that their
headers violated quite routinely (IIRC, a lot of the problems were
with anonymous members, or something on that order).

[ ... ]

Btw g++ also has a huge list of switches to select standard/dialect
and individual features, including for scoping.

Right -- and that matches closely with what MS did in later versions
as well. The compiler could already do the right thing, but they
added individual switches, so you could enforce the correct behavior
that affected a lot of people, while leaving things most people
wouldn't notice. As I recall, they also fixed their headers, so they
would compile regardless of compiler switches (though I seem to
recall looking at some headers and finding that rather than fixing
the code, they'd just added #pragmas to temporarily change compiler
options as needed).

 

[Jerry Coffin]

[ ... ]

Actually, even in VC++ 6, the compiler could/would/did support the
correct scoping of variables defined in a for loop. The problem was
that it was enabled (only) with the "string ANSI conformance

Oops -- that should be "strict ANSI conformance switch".