For Loop Scope

[MiniDisc_2k2]

The post C++ Scope reminded me of a question which has been bothering me for
very long. My compiler decided to do this:

for (int x = 0; x < 10; x++)
std::cout << x;

for (int x = 0; x < 20; x++) // illegal, redefinition of x
std::cout << x;

int x = 0; // legal


Would anyone tell me if this is the standard? No matter what order I put it
in, a second for loop cannot be defined with the same variable, but it can
be redefined outside of a for loop. Why is that? Please tell me this isn't
standard.

-- MiniDisc_2k2
To reply, replace nospam.com with cox dot net.

P.S. Where can I find a handbook or something telling me the C++ standard?

 

[Nick Wightkin]

The post C++ Scope reminded me of a question which has been bothering
me for very long. My compiler decided to do this:

for (int x = 0; x < 10; x++)
std::cout << x;

for (int x = 0; x < 20; x++) // illegal, redefinition of x
std::cout << x;

int x = 0; // legal

It's standard, but not all compilers conform to the standard 100%. Here's a
good article that comments on your problem:
http://www.cuj.com/documents/s=8003/cujcexp1809sutter/

Regards,
Nick

 

[MiniDisc_2k2]

Thanks everyone. That's a strange standard, but I guess I'll have to follow
it. Funny how you all mentioned my compiler (VC++ 6). I intentionally left
it out in my op just to see if you mentioned it...

 

[Jerry Coffin]

Thanks everyone. That's a strange standard, but I guess I'll have to follow
it. Funny how you all mentioned my compiler (VC++ 6). I intentionally left
it out in my op just to see if you mentioned it...

VC++ 6 is mentioned largely because it happens to have effectively
retained the pre-standard behavior long after almost everything else
updated their behavior.

Actually, contrary to another post in this thread, VC++ 6 did not
predate the change in the standard requirements, and the initial release
of VC++ 6 did (and still does) support the correct scope for variables
defined in the header of a for-loop. Unfortunately, this capability is
rendered essentially useless -- it's enforced by asking for the strict
language, but this also enforces a number of other restrictions that
prevent many of the VC++ standard headers from compiling.

IOW, the compiler itself has supports the right scope, but the rest of
the implementation won't work when you use it.

 

[dxcoder]

Actually, contrary to another post in this thread, VC++ 6 did not

predate the change in the standard requirements, and the initial release
of VC++ 6 did (and still does) support the correct scope for variables

yes it did, actually, the beta was available to MSDN Universal subscribers
well before the release and the topic was discussed in the developer
newsgroups. Five years later MSVC++.NET 2002 made the Standard conforming
behaviour the default. The point is that compilers don't magically appear
the day they are released, they are under development for number of years
prior to getting to that point, your mileage may vary naturally.

I'd suggest a compiler upgrade or change, if being up-to-date with the
latest developments is a priority. I'm myself on g++ 3.3 .. and
VisualC++.NET 2003 is the latest offering from Microsoft, if I am not
mistaken.

 

[Jerry Coffin]

yes it did,

Yes it did support the correct scope or yes it did predate the change in
the requirement? It most assuredly did NOT predate the change in the
requirement -- VC++ 6 was published in 1998, and the requirement existed
back at least as far as the committee draft of December 1996.

actually, the beta was available to MSDN Universal subscribers
well before the release and the topic was discussed in the developer
newsgroups.

I'll take your word for this -- I had an MSDN Universal subscription at
the time, and don't remember getting any betas of it, but my memory's a
long ways from perfect.

[ ... ]

I'd suggest a compiler upgrade or change, if being up-to-date with the
latest developments is a priority. I'm myself on g++ 3.3 .. and
VisualC++.NET 2003 is the latest offering from Microsoft, if I am not
mistaken.

Yes -- regardless of anything else, VC++ 6 is clearly out of date from
almost any viewpoint. Admittedly, the current development environment
is a clear step backwards, but the compiler is equally clearly several
steps forward.

 

[dxcoder]

I'll take your word for this -- I had an MSDN Universal subscription at

the time, and don't remember getting any betas of it, but my memory's a
long ways from perfect.

Same thing, but I doubt I'd remember the issue being debated prior to
release, if it wasn't debated.. I have no choise but to trust my memory, it
can't be THAT bad. The sadness that the final release didn't use the correct
scope as default, especially because the <windows.h> didn't pass compiling
when the correct scoping was enabled. So I agree with your assesment, that
the switch was next to useless at the time (still is).


almost any viewpoint. Admittedly, the current development environment

is a clear step backwards, but the compiler is equally clearly several
steps forward.

Haven't tried, so can't comment, but propably will fold back that way sooner
than expected. Any experiences with Intel C++ 7 vs. MSVC++.NET 2003?

 

[Jerry Coffin]

[ ... ]

Haven't tried, so can't comment, but propably will fold back that way sooner
than expected. Any experiences with Intel C++ 7 vs. MSVC++.NET 2003?

Not a lot -- Intel has classically had two advantages and one
disadvantage: it has had better conformance and slightly better
optimization at the expense of substantially slower compilation.

MS has improved conformance to the point that the two are nearly tied on
this score now (close enough that deciding which is closer consists
largely of deciding whether you consider bug X more or less important
than bug Y).

MS seems to have improved optimization a little bit, but the difference
has only rarely been enough for me to care a lot about anyway -- with
the proviso that most of what I do is basically system-type programming,
with very little FP manipulation or anything like that, so it's probably
less open to optimization than most anyway.

The compile times have, unfortunately, remained similar.

The net result is that for me Intel justifies itself so rarely that I
basically don't use it at all, and hesitate to comment on it. Many
people who routinely do lots of floating point work give it their
highest recommendations without hesitation.

At least to me, it seems like it boils down to a question of whether you
use it in ways that justify the long compile times. I rarely do, but
that's just the nature of the work I happen to do.

 

[Stuart Golodetz]

The post C++ Scope reminded me of a question which has been bothering me for
very long. My compiler decided to do this:

for (int x = 0; x < 10; x++)
std::cout << x;

for (int x = 0; x < 20; x++) // illegal, redefinition of x
std::cout << x;

int x = 0; // legal


Would anyone tell me if this is the standard? No matter what order I put it
in, a second for loop cannot be defined with the same variable, but it can
be redefined outside of a for loop. Why is that? Please tell me this isn't
standard.

-- MiniDisc_2k2
To reply, replace nospam.com with cox dot net.

P.S. Where can I find a handbook or something telling me the C++ standard?

Your code as it stands should compile fine. You're looking for this, it
would seem:

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

HTH,

Stuart.

 

[Dhruv]

MS seems to have improved optimization a little bit, but the difference
has only rarely been enough for me to care a lot about anyway -- with
the proviso that most of what I do is basically system-type programming,
with very little FP manipulation or anything like that, so it's probably
less open to optimization than most anyway.

Talking about compilers and optimization, I'd like to vote for g++. Though
it might not be as compiliant as Intel, it sure does optimize well.

Another thing to take into account would be the STL provided by the
compiler. Now, it is more or less a part of the language (more so if I'd
say). The different STLs provided by the vendors have different execution
times, and different levels of standards compliance. The SGI STL has been
undergoing a lot of development, and forking, and with STLPort around, it
has become faster than ever before. I tried performing some benchmarks on
the std::list, and found that g++ outperforms Intel all hands down. Where
g++ took ~3 sec., Intel took ~7 sec. (more than double) for the same code.
All optimizations were enabled. (-O3). No matter how good the compiler is
in optimizing the code, if you have bad code, it will be slow.

g++ uses a fork of the SGI STL, while Intel uses Dinkumware's STL.

 

[Ron Natalie]

Talking about compilers and optimization, I'd like to vote for g++. Though
it might not be as compiliant as Intel, it sure does optimize well.

You have got to be kidding. G++ (at least on the Pentiums) generates
horrendously bad code. The optimizer is absolutely ignorant of the concepts
required to produce good PII code. The Intel compiler is a world of difference.

 

[Jerry Coffin]

[ ... ]

Talking about compilers and optimization, I'd like to vote for g++. Though
it might not be as compiliant as Intel, it sure does optimize well.

I hesitated to mention optimization at all, largely because it's
practically an invitation to a flamewar. Therefore, I'm going to do my
best to be very careful in how I reply to this.

Optimization is a rather strange situation -- though optimization and
testing of it seem like they should both be quite exact sciences, my
experience indicates that they're far less so than most people believe.
I suspect part of the reason for this is that different compilers
produce good code for different kinds of input.

Regardless of the exact reasons, the result is fairly simple: there's
nearly no such thing as a "fair" benchmark in any abstract sense, and
the compiler with which you get the best results seems (in my
experience) to indicate more about the code you write than about the
compiler itself. That's not to say anything about the quality of the
code involved, only that I think people quickly pick up on the odd
quirks of how their compiler generates code, and without conscious
effort (or often even any awareness of it) tailor their code to suit.

The result is that it's virtually impossible to find "neutral" code that
really gives a good indication of the compiler rather than the coder.
The closest I've been able to find (at least of what's easily available)
is a rather large collection of benchmarks named Bench++, compiled (no
pun intended) by Joe Orost. The reason I tend to consider this closer
to "neutral" than most others is fairly simple: an awful lot of the code
is transliterated from FORTRAN, Ada, etc., which helps prevent it from
being tailored to a particular compiler. Another good point is its
sheer size, and the number of different things it tests -- it's hard for
me to imagine that with so many substantially different kinds of tests,
it can keep from giving at least some indication of the compiler's
quality. Nicely enough, it also includes a fair number of Alexander
Stepanov's tests of how a compiler handles different levels of
abstraction, so even if you don't want to compare one compiler to
another, at least part of the results can still be useful and
interesting.

Another thing to take into account would be the STL provided by the
compiler.

IMO, given the relative ease with which it can be replaced, this is a
minor factor at most. Just for an obvious example, I'm pretty sure I've
gotten STLPort set up in under 10 minutes. My experiences with it
haven't matched yours, so I haven't continued to use it on a regular
basis, but getting it set up so I _could_ use it was trivial.