Two questions about declarations in conditions
scott douglass
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' */ }
}
}
2 -- the object is initialized and destroyed on each iteration, making 'f'
above eqivalent to:
void f(int i)
{
while (1) { T t = i; if (!t) break; /* do something with 't' */ }
}
Which is it supposed to be?
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' */ }
}
Which I prefer.
[I was tempted to suggest the tidier
condition:
expression
type-specifier-seq declarator initializer
but that would allow the potentially disagreeable '= { /*...*/ }' form.]
Thanks for your kind attention,
--scott
---
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std...@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++...@ncar.ucar.edu ]
Steve Clamage
(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...@eng.sun.com
scott douglass
: In article 14039615...@193.131.176.202, sdou...@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...@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++...@ncar.ucar.edu
]