For Loop Scope

Discussion in 'C++' started by MiniDisc_2k2, Jun 29, 2003.

  1. MiniDisc_2k2

    MiniDisc_2k2 Guest

    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?
    MiniDisc_2k2, Jun 29, 2003
    #1
    1. Advertising

  2. MiniDisc_2k2 wrote:
    > 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
    Nick Wightkin, Jun 29, 2003
    #2
    1. Advertising

  3. MiniDisc_2k2

    MiniDisc_2k2 Guest

    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...
    MiniDisc_2k2, Jun 30, 2003
    #3
  4. MiniDisc_2k2

    Jerry Coffin Guest

    In article <5kMLa.35555$>,
    says...
    > 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.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Jun 30, 2003
    #4
  5. MiniDisc_2k2

    dxcoder Guest

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


    --
    -xXx-
    dxcoder, Jun 30, 2003
    #5
  6. MiniDisc_2k2

    Jerry Coffin Guest

    In article <bdojdo$e8e$>,
    says...
    > > 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,


    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.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Jun 30, 2003
    #6
  7. MiniDisc_2k2

    dxcoder Guest

    > 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?


    --
    -xXx-
    dxcoder, Jun 30, 2003
    #7
  8. MiniDisc_2k2

    Jerry Coffin Guest

    In article <bdomro$j8h$>,
    says...

    [ ... ]

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

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Jun 30, 2003
    #8
  9. "MiniDisc_2k2" <> wrote in message
    news:I2JLa.35063$...
    > 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.
    Stuart Golodetz, Jul 1, 2003
    #9
  10. MiniDisc_2k2

    Dhruv Guest


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

    > 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.
    Dhruv, Jul 1, 2003
    #10
  11. MiniDisc_2k2

    Ron Natalie Guest

    "Dhruv" <> wrote in message news:p...

    > 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.
    Ron Natalie, Jul 1, 2003
    #11
  12. MiniDisc_2k2

    Jerry Coffin Guest

    In article <>,
    says...

    [ ... ]

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

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Jul 1, 2003
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul Opal
    Replies:
    12
    Views:
    933
    Paul Opal
    Oct 11, 2004
  2. ann
    Replies:
    13
    Views:
    653
    Patricia Shanahan
    Sep 13, 2005
  3. Steven T. Hatton
    Replies:
    9
    Views:
    462
  4. Xah Lee
    Replies:
    0
    Views:
    2,223
    Xah Lee
    Feb 26, 2009
  5. Isaac Won
    Replies:
    9
    Views:
    353
    Ulrich Eckhardt
    Mar 4, 2013
Loading...

Share This Page