Compiler for C++ programming

[Richard Herring]

Just to add my 2d worth: If you _do_ go with VC, do not if you can
possibly avoid it compile to .net,

I'm not sure that you _can_ compile standard C++ (as opposed to C++/CLI)
to .NET - the CLR object model doesn't support some things (e.g.
multiple inheritance) that are quite important for C++.

Or have they changed that in .NET 3, or whatever version its up to now?

 

[Jerry Coffin]

[ ... ]

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++.

I'm also going from personal use, and would say exactly the same, but
in reverse. Some here have probably seen me say it before, but I'll
repeat: I suspect people adapt to their compiler of choice, so they
have a strong tendency to avoid writing code it won't handle. That's
probably happened to both of us.

Perhaps g++ really is tied with VC++ for conformance, rather than
being behind -- and possibly it's even slightly better (though that
certainly doesn't match my own experience). I'm pretty sure I could
easily write an "objective" benchmark showing that either had clearly
superior conformance to the other.

Looking back at the failures I've seen from the two, I'd probably
agree that looking strictly at the compiler itself, g++ really is
better -- but I've yet to see a standard library for g++ that's comes
nearly as close to conforming as VC++'s.

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).

Which seems to go back to what I said above. I probably run g++ once
every couple of weeks or so, and can count on at least one crash
virtually every time I try to use it. I run VC++ virtually every day,
and I believe I've had it crash once this year...

 

[James Kanze]

If you have code which reuses a loop variable (like i) for
another later loop, it can also cause problems. Or is that bad
practice?

Well, it certainly doesn't help readability. Within a function,
it's usual practice to give all variables different names,
regardless. And of course, if a function contains two
successive loops, one really should ask if it shouldn't be two
different functions.

 

[James Kanze]

"James Kanze" <[email protected]>

You used another one, that failed.

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

OK. I'll buy the fact that it could get in the way of
obfuscation (using the same name for two different variables,
writing functions which do too much, etc.).

 

[Balog Pal]

OK. I'll buy the fact that it could get in the way of
obfuscation (using the same name for two different variables,
writing functions which do too much, etc.).

Come on. You know better that it is not obfuscation to write functions
naturally to express what is going on, instead of following abstract
'good-for-all-situations' guidelines, forcing 'ravioli code'.

Some function are just long, and getting forcibly split to more functions,
or converted to a functions object is simply a bad transformation by all
practical means.

Also, inventing a new, non-idiomatic name for a variable just becase it was
used at some other, losely related part of the program hurst more than
helps. 'Scope' was introduced to the language for a good reason, with all
the hiding and separating.

IMO it is perfetly normal to use i,j,k as the integral for-loop variable,
and stick to that. With j indicating a *nested* loop inside i, and so on.

And the schange of scoping of 'for', accepting the rare declination from
back-compatibility was a good decision, the 'i' do not escape its loop, so
using it in another *top-level* loop would be confusing how?

Especially as the loop body is indeed a good candidate for more agressive
'shortening'.

 

[Juha Nieminen]

VC++ 6 was notoriously non-compliant in many respects

I'm really wondering why VC++ 6 seems to be still so popular nowadays
even though you can updgrade Visual Studio to the latest version for
free (with most of the important functionalities available).

 

[Juha Nieminen]

OK. I'll buy the fact that it could get in the way of
obfuscation (using the same name for two different variables,
writing functions which do too much, etc.).

I really can't see the problem you are trying to imply there. This
kind of code isn't in any way obfuscated, overly long or anything. It's
simple and straightforward, and easy to read, and IMO very good code:

void foo()
{
for(int index = 0; index < container.size(); ++index)
doSomeOperationTo(container, index);

for(int index = 0; index < container.size(); ++index)
doAnotherOperationTo(container, index);
}

(There are many situations where the two operations being performed
cannot be done inside the same loop, but the first operation has to be
performed to all the elements before the second one can.)

Splitting that function into two functions would not increase
readability. Following the flow of the program becomes more complicated.

 

[Juha Nieminen]

For instance, I'm still using VC++2005 rather than 2008 for any serious work
because I want to be able to work on my code in the lab as well as at
home.

Are VC++2005 and VC++2008 project files incompatible with each other
(or more relevantly, are VC++2008 project files incompatible with VC++2005)?

If that's so, it feels absolutely silly, if not outright idiotic. It
would be like makefiles not working on a unix-style environment if you
used gcc 3.x instead of gcc 4.x.

A project file (like a makefile) should be completely independent of
the compiler version being used. Else everything is going to break when
a new version comes out, and people upgrade only gradually.

 

[Puppet_Sock]

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

Urgh...

There were lots of work-arounds, depending on your taste and
how accepting of compiler-specific code you are.

Example: Put another {} pair around it like so.
(Done at keyboard so could be some typo-syntax-flubs.)

{
int i;
for(i=0;i<10;i++)
// loop stuff
}

Then it works the same in VC6 as a compliant compiler.

Happily, later versions are closer to compliance. I'm not
sure if any compiler is absolutely compliant. But on the
other hand, along with four fingers and a thumb, there's
the old story about the new coder who was so sorry to not
get to meet the guy who recently left. The old, now fired,
guy made it a point to use every feature of the language
in every program.

There's a lesson here someplace, I just know it.

To the OP: The best place to learn C++ is using any recent
compiler, and a couple good texts.
Socks

 

[Balog Pal]

Happily, later versions are closer to compliance. I'm not
sure if any compiler is absolutely compliant. But on the
other hand, along with four fingers and a thumb, there's
the old story about the new coder who was so sorry to not
get to meet the guy who recently left. The old, now fired,
guy made it a point to use every feature of the language
in every program.

There's a lesson here someplace, I just know it.
<<

But with missing the key information the lesson can not be learned.

Every feature of the language can be used properly and improperly. And for
any problem there is a bunch of different solutions with different
attributes -- built with different features used.

If the old guy used the features for good, well done, if just to show off,
bad. Can you tell from far away?

Not using the proper features that are available in the language and picked
implementations -- just in fear of 'some of out programmers may not be up to
them' is simply bad, and the highway to WTF land. The solution being to
bring up the programmers to the needed level trhough education or
replacement.

Instead of crippling the project to 'incompetent programmer' level, hoping
it will work. Experience showed every time it will not. but just will go
downhill and losing all hope of reparations, as competent people will leave
soon for a better place.

 

[Jerry Coffin]

I'm really wondering why VC++ 6 seems to be still so popular nowadays
even though you can updgrade Visual Studio to the latest version for
free (with most of the important functionalities available).

The next version was Visual Studio .NET, which had a somewhat better
compiler, but a _dramatically_ worse IDE. Since then, they've
improved both the compiler and the IDE. While the improvements to the
compiler have been quite large, those to the IDE have been fairly
small -- small enough that it's still clearly inferior to VS 6.