dougm@cs.cs.rice.edu (Doug Moore) writes:
: In article <1993Oct2.203755.29310@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
:    In fact, better:
:
:     if( Mac *mm = dynamic_cast<Mac *>(f) )
:         {
:         // some Mac specific thing
:         }
:
:    Declarations are now allowed in 'if' and 'while' statements.
:    The scope of the variable is the stuff in the curly brackets.
:
:    (As opposed to 'for', where the scope of a declaration
:    in the initialiser is the rest of the block containing the for)
:
: Has the committee presented a rationale for this divergence from the
: convention established with 'for'?  Why treat them differently?

Presumably so that it can be used for type-safe downcasting.
If the test fails, control goes to where the variable is not defined.
Don't know what happens if there isn't an if around the declaration,
though.  Maybe it should be a syntax error to have a downcasting
declaration where there isn't an 'if' or a 'while' around it?
--
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work: hendrik@vedge.com,  iros1!vedge!hendrik
at home: uunet!ozrout!topoi!hendrik

In article <1993Oct07.164925.9091@vedge.com> hendrik@vedge.com (Hendrik Boom) writes:
>dougm@cs.cs.rice.edu (Doug Moore) writes:
>: In article <1993Oct2.203755.29310@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>:    In fact, better:
>:
>:     if( Mac *mm = dynamic_cast<Mac *>(f) )
>:         {
>:         // some Mac specific thing
>:         }
>:
>:    Declarations are now allowed in 'if' and 'while' statements.
>:    The scope of the variable is the stuff in the curly brackets.
>:
>:    (As opposed to 'for', where the scope of a declaration
>:    in the initialiser is the rest of the block containing the for)
>:
>: Has the committee presented a rationale for this divergence from the
>: convention established with 'for'?  Why treat them differently?
>
>Presumably so that it can be used for type-safe downcasting.
>If the test fails, control goes to where the variable is not defined.

 Thats backwards. The reason is that in a multi-way
if/then/else chain:

 X2* y=new X2;
 if(X1* x1 = dynamic_cast<X1*>(y) { .. }
 else if(X2* x2 = dynamic_cast<X2*>(y) { .. }
 else if(X3* x3 = dynamic_cast<X3*>(y) { .. }

 x3; //??

if the scope of the declarations extend beyond the control
of the 'if' then x3 is visible but has not been initialised.

>Don't know what happens if there isn't an if around the declaration,
>though.  Maybe it should be a syntax error to have a downcasting
>declaration where there isn't an 'if' or a 'while' around it?

 No, the pointer just gets set to zero if the cast fails.
You can perform a test on it later. (You can forget to as well,
but C/C++ isnt safe anyhow .. :-)

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <1993Oct14.002846.13197@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:

>> : Has the committee presented a rationale for this divergence from the
>> : convention established with 'for'?  Why treat them differently?
>
>Because they are different beasts.  This declaration is right there in
>the test; in the  for  the declaration is in the initializer.  They are
>different places and places of different kinds.

 Not much excuse though. I seem to recall there is
actually a reason, but I cant think of it.

 I do know that THIS:

 for(int i=0; ...
 for(int i=0; ... // duplicate definition

or

 for(j =0; // j undefined

is one of the most frequent error I get.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <1993Oct07.164925.9091@vedge.com>, hendrik@vedge.com (Hendrik Boom) writes:
> dougm@cs.cs.rice.edu (Doug Moore) writes:
> : In article <1993Oct2.203755.29310@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
> :    In fact, better:

> :     if( Mac *mm = dynamic_cast<Mac *>(f) )
> :         {
> :         // some Mac specific thing
> :         }

> :    Declarations are now allowed in 'if' and 'while' statements.
> :    The scope of the variable is the stuff in the curly brackets.
 ...
> : Has the committee presented a rationale for this divergence from the
> : convention established with 'for'?  Why treat them differently?

Because they are different beasts.  This declaration is right there in
the test; in the  for  the declaration is in the initializer.  They are
different places and places of different kinds.

> Presumably so that it can be used for type-safe downcasting.
> If the test fails, control goes to where the variable is not defined.
> Don't know what happens if there isn't an if around the declaration,
> though.  Maybe it should be a syntax error to have a downcasting
> declaration where there isn't an 'if' or a 'while' around it?

You get a null pointer.  Very well defined, very well behaved, useful from
time to time.  There's no need for restrictions on the form of code.
--
 (This man's opinions are his own.)
 From mole-end    Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ

In article <1993Oct2.203755.29310@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
   In fact, better:

    if( Mac *mm = dynamic_cast<Mac *>(f) )
        {
        // some Mac specific thing
        }

   Declarations are now allowed in 'if' and 'while' statements.
   The scope of the variable is the stuff in the curly brackets.

   (As opposed to 'for', where the scope of a declaration
   in the initialiser is the rest of the block containing the for)

Has the committee presented a rationale for this divergence from the
convention established with 'for'?  Why treat them differently?

Can we (please) deprecate the use of the for-declared variable outside
the scope of the for statement (the stuff inside the curly brackets)?
As assignment to this has been phased out, so can be this language
design error (IMHO), and the semantics of for-declarations and
while-declarations can be made similar again.

And, what is the meaning of

if (int i = 1, *p = 0)
  {
    // executed or not?
  }

Anybody know?

Doug Moore
(dougm@cs.rice.edu)