dhunter@lehman.com writes:

>My comment about whether old style casts are, or will be, anachronistic
>was an indirect way of asking the following. Will compilers ever flag
>old style casts, which they would presumably do, as they do for other
>anachronistic constructs. This would make the task of finding existing
>casts and enforcing there non-usage in future much easier.

Compilers can generate messages about anything they like. An
optional warning about old-style casts would be useful, whether or
not they are ever declared anachronistic in the C++ standard.
Ask your favorite vendor to supply the warning.

--
Steve Clamage, stephen.clamage@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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <371D1D05.A2F4233A@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> Steve Clamage wrote:
> >
> > James Kuyper <kuyper@wizard.net> writes:
> ....
> > >Deciding which of the new-style cast should
> > >be used to replace a C-style cast is highly non-trivial.
> >
> > Given an arbirary expression containing a cast, it might take
> > some research to reconstruct the reason for using the cast.
>
> That's precisely the part of the process that I was thinking of when I
> said "highly non-trivial". In the context of trying to fix-up large
> quantities of legacy code, such research would be a significant cost.
>

Part of the reasoning for modifying the code, which does not in
this case happen to be "legacy", was that replacing
old style casts with new style makes the purpose of the cast more
apparent, will possibly elimate some existing errors and also
make the code more maintainable in future.

Maybe I should have put the question as the following.
Given that I have some existing code in which I want to replace old style
with new what is the easiest way.

My comment about whether old style casts are, or will be, anachronistic
was an indirect way of asking the following. Will compilers ever flag
old style casts, which they would presumably do, as they do for other
anachronistic constructs. This would make the task of finding existing
casts and enforcing there non-usage in future much easier.

David


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:

>dhunter@lehman.com wrote:
>>
>> After a search through the C++ standard, and old posts on this group,
>> I could not find any indication as to whether old style casts should now be
>> reguarded as anachronistic. Can anyone shed light on this?

>C-style casts are dangerously powerful, and everything they can do can
>now be done by less dangerous methods.

Almost everything. If you have an object of, pointer to, or reference
to a class type, only a C-style cast can convert it to an inaccesible
base class type.

>Deciding which of the new-style cast should
>be used to replace a C-style cast is highly non-trivial.

Given an arbirary expression containing a cast, it might take
some research to reconstruct the reason for using the cast.
One you know the reason, the equivalent cast(s) is easy to
determine.

--
Steve Clamage, stephen.clamage@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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
>
> James Kuyper <kuyper@wizard.net> writes:
....
> >Deciding which of the new-style cast should
> >be used to replace a C-style cast is highly non-trivial.
>
> Given an arbirary expression containing a cast, it might take
> some research to reconstruct the reason for using the cast.

That's precisely the part of the process that I was thinking of when I
said "highly non-trivial". In the context of trying to fix-up large
quantities of legacy code, such research would be a significant cost.

> One you know the reason, the equivalent cast(s) is easy to
> determine.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>After a search through the C++ standard, and old posts on this group,
>I could not find any indication as to whether old style casts should now=
 be
>reguarded as anachronistic. Can anyone shed light on this?

Section 5.4 of the standard explicitly describes these casts as=20
"explicit type conversion". It describes how it works and does
not mention it to be deprecated or anything similar.


5.4 Explicit type conversion (cast notation)

1 The result of the expression (T) cast=ADexpression is of type T. The

  result is an lvalue if T is a reference type, otherwise the result
  is an rvalue. [Note: if T is a non=ADclass type that is cv=ADqualified,
  the cv=ADqualifiers are ignored when determining the type of the
  resulting rvalue; see 3.10. ]

2 An explicit type conversion can be expressed using functional=20
  notation (5.2.3), a type conversion operator (dynamic_cast,
  static_cast, reinterpret_cast, const_cast), or the cast notation.
     cast=ADexpression:=20
        unary=ADexpression
           ( type=ADid ) cast=ADexpression

3 Types shall not be defined in casts.

4 Any type conversion not mentioned below and not explicitly defined
  by the user (12.3) is ill=ADformed.

5 The conversions performed by
    =97 a const_cast (5.2.11),
    =97 a static_cast (5.2.9),
    =97 a static_cast followed by a const_cast,
    =97 a reinterpret_cast (5.2.10), or
    =97 a reinterpret_cast followed by a const_cast,
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 16 Apr 99 06:54:59 GMT, James Kuyper <kuyper@wizard.net> wrote:

>C-style casts are dangerously powerful, and everything they can do can
>now be done by less dangerous methods. They should be avoided, but that
>fact has not been made a part of the standard. They aren't marked as
>deprecated, which would be the first step toward removing them
>completely.

Not only that.  The C style casts may be combinations of C++ style
casts.  Eg,
   Base const * b;
   Derived * d=(Derived *)b; // static_cast + const_cast
Granted, this usage is rare.


>One of the key reasons why the C-style casts are bad, is that there's no
>good way to search for them. That was probably also a factor in deciding
>not to deprecate them - it would be very difficult to automatically
>replace them in legacy code. Deciding which of the new-style cast should
>be used to replace a C-style cast is highly non-trivial.

Another reason to prefer C++ style casts is that they afford some degree
of compile time checking.
   [X] static_cast from A* to B*
       the compiler must know that A derives from B or B derives from A
       for A==void or B==void, there's never a problem
   [X] static_cast from A& to B&
       same as above
   [X] static_cast from A to B
       there must be a conversion B::B(const A&) or A::operator B() const
       the constructor may be explicit or implicit
       we can pretend that there exist constructors int::int(const short&)
   [X] dynamic_cast from A* to B*
       the compiler must know that class A is polymorphic

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

dhunter@lehman.com wrote:
>
> After a search through the C++ standard, and old posts on this group,
> I could not find any indication as to whether old style casts should now be
> reguarded as anachronistic. Can anyone shed light on this?

C-style casts are dangerously powerful, and everything they can do can
now be done by less dangerous methods. They should be avoided, but that
fact has not been made a part of the standard. They aren't marked as
deprecated, which would be the first step toward removing them
completely.

> Also, if they are not, or if the compiler I am using does not flag where
> they occur, are there any suggestions how I can find them and remove
> them most easily from existing code? Note that this is not a question
> concerning whether casts in general are good/bad/indifferent etc...

One of the key reasons why the C-style casts are bad, is that there's no
good way to search for them. That was probably also a factor in deciding
not to deprecate them - it would be very difficult to automatically
replace them in legacy code. Deciding which of the new-style cast should
be used to replace a C-style cast is highly non-trivial.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

After a search through the C++ standard, and old posts on this group,
I could not find any indication as to whether old style casts should now be
reguarded as anachronistic. Can anyone shed light on this?

Also, if they are not, or if the compiler I am using does not flag where
they occur, are there any suggestions how I can find them and remove
them most easily from existing code? Note that this is not a question
concerning whether casts in general are good/bad/indifferent etc...

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]