Searching \ for '[EE] MS C++ compiler for loops different?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/language/index.htm?key=c%2B%2B
Search entire site for: 'MS C++ compiler for loops different?'.

Exact match. Not showing close matches.
PICList Thread
'[EE] MS C++ compiler for loops different?'
2006\10\12@143349 by James Newton, Host

face picon face
{Quote hidden}

Huh? I don't see any difference. Does the extra set of braces matter?

> Precluding something like:
>
> for ( int i = 0; i < COUNT; i++ )  // Legal C++ { }

Are you saying that this doesn't work in the MS compiler?

> for ( i = 0; i < COUNT; i++ )  // Error, i is undefined { }

Which is correct assuming "i" was not defined earlier...

---
James.





2006\10\12@150804 by Orin Eman

picon face
On 10/12/06, James Newton, Host <spam_OUTjamesnewtonTakeThisOuTspampiclist.com> wrote:
{Quote hidden}

There is plenty of C++ code out there using:

for ( int i = 0; ...

and later in the same block:

for ( i = 0; ...

assuming that the first is shorthand for:

int i;
for ( i = 0; ...

Adding the extra braces to the while version hides the definition of i
from subsequent code and is contrary to section 6.5.3 of my copy of
the Annotated C++ Reference Manual, but it's effectively what
Microsoft's latest compiler is doing.

The Reference Manual does comment that on balance,it would have been
better to limit the scope of such a declaration to the for statement,
but says "much code now exists" on the scope being to the end of the
block containing the for statement.

Orin.

2006\10\12@152509 by peter green

flavicon
face

> The Reference Manual does comment that on balance,it would have been
> better to limit the scope of such a declaration to the for statement,
> but says "much code now exists" on the scope being to the end of the
> block containing the for statement.

iirc apps built with visual C++ .net also crash on an attempt to read an
uninitialised variable.

i think this is all a part of microsofts plan to get tougher on sloppy
coding practices that can potentially cause holes both in windows itself and
in windows apps.

2006\10\12@155544 by James Newtons Massmind

face picon face
{Quote hidden}

Ah, now I understand. I guess I can see both sides of that... And Microsoft
is not known for staying with the standards are they? :o)

Thanks for explaining.

---
James.


2006\10\12@160029 by Peter Bindels

picon face
On 12/10/06, Orin Eman <.....orin.emanKILLspamspam@spam@gmail.com> wrote:
> On 10/12/06, James Newton, Host <jamesnewtonspamKILLspampiclist.com> wrote:
> > Are you saying that this doesn't work in the MS compiler?
> >
> > > for ( i = 0; i < COUNT; i++ )  // Error, i is undefined { }
> >
> > Which is correct assuming "i" was not defined earlier...
>
> Adding the extra braces to the while version hides the definition of i
> from subsequent code and is contrary to section 6.5.3 of my copy of
> the Annotated C++ Reference Manual, but it's effectively what
> Microsoft's latest compiler is doing.
>
> The Reference Manual does comment that on balance,it would have been
> better to limit the scope of such a declaration to the for statement,
> but says "much code now exists" on the scope being to the end of the
> block containing the for statement.

Get an updated reference manual, that's all I can really say. As far
as I can tell that has been so since C++ version 98 or since C version
99. It's also more intuitive for new people, although you can disagree
with that. The version numbers indicate the year they were brought
out, your compiler should comply with that for about 7-8 years now. Of
course, MS C++ isn't really trusted for standards adherence but in
this case you must give them the benefit of the doubt.

2006\10\12@160303 by Peter Bindels

picon face
On 12/10/06, peter green <.....plugwashKILLspamspam.....p10link.net> wrote:
> iirc apps built with visual C++ .net also crash on an attempt to read an
> uninitialised variable.
>
> i think this is all a part of microsofts plan to get tougher on sloppy
> coding practices that can potentially cause holes both in windows itself and
> in windows apps.

The first is a coding error that assumes something that needn't be
true, and is as far as I can tell only in debug builds.

Microsoft is getting tighter on "sloppy" coding practices, or coding
practices they doesn't understand themselves, partly by disallowing
the code in normal mode but mostly by strongly inducing you to convert
to a language not decided by standard but by Microsoft themselves. In
which they explicitly ban all things they don't want you to do. I've
already had more than one collision with MSVS that just plain said "No
I won't do that" even though it knew damn well what I was trying to
do. Try fallthroughs in switches in c#.

2006\10\12@174002 by Gerhard Fiedler

picon face
James Newton, Host wrote:

{Quote hidden}

Yes. You can declare variables in expression1, and the presence or not of
the (invisible) extra set of braces determines the scope of the variables
that are defined in expression1. Without the extra set, they are valid
until the end of the enclosing block (whatever that is); with it, they are
valid only within the for loop.


The problem is that the definition with the extra set of braces has been
standard for ten years or more, but some compilers didn't handle it this
way and may now be moving towards the standard. See for example
http://www.csci.csusb.edu/dick/c++std/cd2/stmt.html (dated 11/1996) and
browse to section 6.5.3:

----- quote -----

 6.5.3  The for statement                                    [stmt.for]

1 The for statement
         for ( for-init-statement conditionopt ; expressionopt ) statement
 is equivalent to

         {
                 for-init-statement
                 while ( condition ) {
                         statement
                         expression ;
                 }
         }
 except  that  names declared in the for-init-statement are in the same
 declarative-region as those declared in the condition, and except that
 a  continue in statement (not enclosed in another iteration statement)
 will execute expression before re-evaluating condition.   [Note:  Thus
 the  first statement specifies initialization for the loop; the condi-
 tion (_stmt.select_) specifies a test,  made  before  each  iteration,
 such  that  the  loop  is exited when the condition becomes false; the
 expression often specifies incrementing that is done after each itera-
 tion.  ]

2 Either  or both of the condition and the expression can be omitted.  A
 missing  condition  makes  the  implied  while  clause  equivalent  to
 while(true).

3 If  the  for-init-statement is a declaration, the scope of the name(s)
 declared extends to the end of the for-statement.  [Example:
         int i = 42;
         int a[10];

         for (int i = 0; i < 10; i++)
                 a[i] = i;

         int j = i;        // j = 42
  --end example]

----- end quote -----


Some VC++ background on this issue: http://vcfaq.mvps.org/lang/1.htm

There is probably a compiler switch that allows selecting one or the other
interpretation.

Gerhard

2006\10\12@183401 by Gerhard Fiedler

picon face
James Newton, Host wrote:

{Quote hidden}

Yes. You can declare variables in expression1, and the presence or not of
the (invisible) extra set of braces determines the scope of the variables
that are defined in expression1. Without the extra set, they are valid
until the end of the enclosing block (whatever that is); with it, they are
valid only within the for loop.


The problem is that the definition with the extra set of braces has been
standard for ten years or more, but some compilers didn't handle it this
way and may now be moving towards the standard. See for example
http://www.csci.csusb.edu/dick/c++std/cd2/stmt.html (dated 11/1996) and
browse to section 6.5.3:

----- quote -----

 6.5.3  The for statement                                    [stmt.for]

1 The for statement
         for ( for-init-statement conditionopt ; expressionopt ) statement
 is equivalent to

         {
                 for-init-statement
                 while ( condition ) {
                         statement
                         expression ;
                 }
         }
 except  that  names declared in the for-init-statement are in the same
 declarative-region as those declared in the condition, and except that
 a  continue in statement (not enclosed in another iteration statement)
 will execute expression before re-evaluating condition.   [Note:  Thus
 the  first statement specifies initialization for the loop; the condi-
 tion (_stmt.select_) specifies a test,  made  before  each  iteration,
 such  that  the  loop  is exited when the condition becomes false; the
 expression often specifies incrementing that is done after each itera-
 tion.  ]

2 Either  or both of the condition and the expression can be omitted.  A
 missing  condition  makes  the  implied  while  clause  equivalent  to
 while(true).

3 If  the  for-init-statement is a declaration, the scope of the name(s)
 declared extends to the end of the for-statement.  [Example:
         int i = 42;
         int a[10];

         for (int i = 0; i < 10; i++)
                 a[i] = i;

         int j = i;        // j = 42
  --end example]

----- end quote -----


Some VC++ background on this issue: http://vcfaq.mvps.org/lang/1.htm

There is probably a compiler switch that allows selecting one or the other
interpretation.

Gerhard

2006\10\12@231708 by Tony Smith

picon face
> > iirc apps built with visual C++ .net also crash on an
> attempt to read
> > an uninitialised variable.
> >
> > i think this is all a part of microsofts plan to get
> tougher on sloppy
> > coding practices that can potentially cause holes both in windows
> > itself and in windows apps.
>
> The first is a coding error that assumes something that
> needn't be true, and is as far as I can tell only in debug builds.
>
> one collision with MSVS that just plain said "No I won't do
> that" even though it knew damn well what I was trying to do.
>
> Try fallthroughs in switches in c#.


C# isn't C, so not everything will work.  Fallthroughs in switches always
was a dumb idea, IIRC no other language does that.

Causes lots of bugs, shuffling the switches around breaks it, some
programmer spots the missing break & adds it, and so on.

Fallthroughs?  Good riddance.

Tony

2006\10\12@235734 by Orin Eman

picon face
On 10/12/06, Gerhard Fiedler <EraseMElistsspam_OUTspamTakeThisOuTconnectionbrazil.com> wrote:
{Quote hidden}

Yes, /Zc:forScope or something like that... going to have to add it to
my old projects at work as we upgrade so we'll at least get a warning.

Orin.

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...