In article LAA18046@mag1.magmacom.com, Marc Sherman <msherman@mag1.magmacom.com> writes:
>In my previous posting, a typo completely obscured my question:
>>
>>Does this mean that an expression type(val) can result in a
>>reinterpret_cast<type>(val)?  I'd thought that static_cast was the only
> ^^^^^^^^^^^ (was dynamic_cast)
>>type of cast allowed by this syntax.
>
>So, in other words, is:
>
> class Foo{} foo;
> int i = int(&foo);
>
>a legal use of this syntax?  I'd like the second line to be equivalent
>to int i = static_cast<int>(&foo), but the way I read the standard, it's
>equivalent to int i = (int)(&foo), which means that the new constructor
>call syntax is yet another un-grep-able way to unsafely cast objects.

I'm still not sure what your question is. The syntax int(something)
for a cast has always been allowed in C++, and has always been
equivalent to (int)(something). Let's call both of these notations
"old-style casts".

Both forms were required, because a constructor is in fact a type
conversion, as is a type cast. A constructor may have more than one
argument, and for example given type T, the notation
 (T)(x, y, z)
cannot invoke a constructor with 3 arguments. (It evaluates x, then y,
then z, then converts the value of z to type T.) Thus
 T(x, y, z)
must be a type conversion, and so therefore must
 T(x)
On the other hand
 char*(x)
can't be a valid cast, so the C syntax
 (char*)x // or (char*)(x)
must also be allowed. It must be allowed for C compatibility anyway.

Instead of making special-case rules depending on the form of the type,
the two forms were decreed to be equivalent in cases where both were
valid syntactically.

The NEW casts are const_cast, static_cast, reinterpret_cast, and dynamic_cast.
The first three are specializations of the old cast notations. Every
valid old-style cast is equivalent to a const_cast, or to a static_cast or
reinterpret_cast possibly followed by a static_cast. The draft standard
now describes old-style casts in terms of the new-style casts. There was
never any intention to change the meaning of existing casts.

In your example, int(&foo) is not valid as a static_cast, so it is
equivalent to reinterpret_cast<int>(&foo), with implementation-defined
semantics.

In part because old-style casts are difficult to find, you no longer need
to use any old-style casts in your code at all. It still makes sense
to write T(x) when you are deliberately constructing a T object, but
you can write static_cast<T>(x) if you want. And instead of writing
int(&foo) you should write reinterpret_cast<int>(&foo), to make it
clear that you are doing something unportable.
---
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 JAA02459@taumet.eng.sun.com, clamage@taumet.eng.sun.com (Steve Clamage) writes:
>
>The NEW casts are const_cast, static_cast, reinterpret_cast, and dynamic_cast.
>The first three are specializations of the old cast notations. Every
>valid old-style cast is equivalent to a const_cast, or to a static_cast or
>reinterpret_cast possibly followed by a static_cast.
                                         ^^^^^^^^^^^ const_cast
> The draft standard
>now describes old-style casts in terms of the new-style casts. There was
>never any intention to change the meaning of existing casts.

Oops. Sorry for any confusion.
---
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 my previous posting, a typo completely obscured my question:

In article <199609301602.MAA12400@mag1.magmacom.com>,
Marc Sherman  <msherman@magmacom.com> wrote:
>Looking through the April '95 DWP, I've come accross an interpretation
>that I'm unsure of regarding casting using the constructor syntax:
>
>Section 5.2.3.1 [expr.type.conv]
>... If the expression list specifies a single value, the expression
>is equivalent ... to the corresponding cast expression (expr.cast).
>
>Section 5.4.4 [expr.cast]
>... The conversions performed by static_cast, reinterpret_cast, const_cast,
>or any sequence thereof, can be performed using the cast notation of
>explicit type conversion.
>
>Does this mean that an expression type(val) can result in a
>reinterpret_cast<type>(val)?  I'd thought that static_cast was the only
 ^^^^^^^^^^^ (was dynamic_cast)
>type of cast allowed by this syntax.

So, in other words, is:

 class Foo{} foo;
 int i = int(&foo);

a legal use of this syntax?  I'd like the second line to be equivalent
to int i = static_cast<int>(&foo), but the way I read the standard, it's
equivalent to int i = (int)(&foo), which means that the new constructor
call syntax is yet another un-grep-able way to unsafely cast objects.

--
 Marc Sherman |  "What? Rhesus Peasus? | work mailto:marcsh@corel.ca
   CorelDRAW! | Latin. Must be Latin." | personal mailto:msherman@magmacom.com
for Macintosh |  - Edward Ka-Spel, LPD | http://www2.magmacom.com/~msherman/


[ 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                             ]