🚀 go-pugleaf

In article 1403961511110001@193.131.176.202, sdouglas@armltd.co.uk
(scott douglass) writes:

>I read section 6.4 carefully but I couldn't decide what the lifetime (not
>scope) of an object declared in the condition of a while or for statements
>is.  Reading D&E 3.11.5.2 didn't help either.  Given the following:

>struct T { T(int); ~T(); operator bool() const; /*...*/ };
>
>void f(int i)
>    {
>    while (T t = i) { /* do something with 't' */ }
>    }

>There are two "obvious" possibilities, I9m leaning toward the first:

>1 -- The object is initialized just once and destroyed just once, making
>'f' above eqivalent to:

>void f(int i)
>    {
>        {
>        T t = i;
>        while (t) { /* do something with 't' */ }
>        }
>    }

Interesting question, and I believe your preferred interpretation is
correct. Here's why: It is clear from the definition of "while" that
the controlled statements that are iterated are those which follow the
condition; the condition is not part of the iterated statement or block.
Further, the *value* of the condition determines whether the controlled
statements are executed. The condition is not a statement, and so
only its value is recomputed; the definition is not re-executed.

Besides, it would be rather pointless if in your example 't' was set to
'i' each time around the loop.


>Bonus question:  why does the grammer allow only the '=
>assignment-expression' form:

>          condition:
>                  expression
>                  type-specifier-seq declarator = assignment-expression

>instead of:

>          condition:
>                  expression
>                  type-specifier-seq declarator = assignment-expression
>                  type-specifier-seq declarator ( expression-list )

>So that I could write:

>void f(int i)
>    {
>    while (T t(i)) { /* do something with 't' */ }
>    }

I think the general case could lead to ambiguities in parsing. If a
function call can possibly be interpreted as a variable definition, then
it is a variable definition. That could lead to unexpected behavior
which would be difficult to track down.

You can always write the same thing with "=" notation:
	while( T t = T(i) ) { ... }
This rewrite is not guaranteed to be as efficient, but most compilers
do optimize away the extra copy.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4ikkbu$b5u@engnews1.Eng.Sun.COM>, clamage@Eng.Sun.COM wrote:

: In article 1403961511110001@193.131.176.202, sdouglas@armltd.co.uk
: (scott douglass) writes:
: >[...]
: >Bonus question:  why does the grammer allow only the '=
: >assignment-expression' form:
: 
: >[grammar to allow 'while (T t(i)) { /* ... */]
: 
: I think the general case could lead to ambiguities in parsing. If a
: function call can possibly be interpreted as a variable definition, then
: it is a variable definition. That could lead to unexpected behavior
: which would be difficult to track down.
: 
: You can always write the same thing with "=" notation:
:         while( T t = T(i) ) { ... }
: This rewrite is not guaranteed to be as efficient, but most compilers
: do optimize away the extra copy.

It is not the same if the copy-constructor for T is private (say, as part
of preventing copying of Ts) and the constructor from the type of 'i' is
public, as is the case in at least one class I have.  Then only the 'T
t(i)' form is legal.
    --scott
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]