Reading this  proposal  and rereading the  DWP,  I started some random
thoughts (sorry if this has been discussed before)...

Why was  it  decided  that const_cast,  dynamic_cast,  etc,  should be
operators instead of  template functions (ok, operators are functions,
anyway, but this  is not the  point).  Making  them template functions
would permit the kind  of specialization Scott Johnson  suggested, but
compilers would still  have the  standard implementation built-in  for
standard    types, such  as    pointers  and  references, to   prevent
mistakes.

Then, one would be able to write:

template <class T> T* dynamic_cast(const Pointer<T>);

that I consider a much simpler form of achieving the same target Scott
Johnson intends to.

--
Alexandre Oliva
oliva@dcc.unicamp.br
Universidade Estadual de Campinas, S=E3o Paulo, Brasil


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

I've got a smart pointer clas I've been working on, and I would like to be
able to dynamic casts on these smart pointers.

One way to do it to try and use implicit casts to and from normal
pointers, and just use the built-in dynamic cast operator....but I'd
really love to avoid doing this.  Scott Meyers gives some rather good
reasons to disallow implicit conversion from a Pointer<T> to a T* in his
book.

I can fake it, if I'm willing to change the lower case d to a capital D,
like this:

template <class T>
class Pointer {
    private:
 T* ptr_;
 Pointer( const T* ptr = 0 ) : ptr_ (ptr) {}
 // other stuff

 template <class U>
 static Pointer<U> Dynamic_cast( const Pointer<T>& Ptr)
 {
     return Pointer<U> = dynamic_cast<U*> (Ptr.ptr_ );
 }
};

but it might be nice to be able to overload dynamic_cast in the language:

Currently, the following forms of dynamic_cast are defined:

dynamic_cast <T*>(foo), where foo is a pointer of some sort and T is a
type, and

dynamic_cast<T&>(foo), where T is a type of some sort., and foo is an
lvalue.

Currently, dynamic_cast<T>, where T is not a pointer nor a reference, is
illegal.  Likewise, dynamic_cast<T*>(foo), where foo is not a pointer, is
also a no-no (unless there is an implicit cast between a foo and a pointer
of some sort).  These two cases could be used for overloading of
dynamic_cast.

In the first case, classes could define a member function
operator dynamic_cast T ();

such that a call of dynamic_cast<T>(foo) is equivalent to
foo.operator dynamic_cast T();

Likewise, the second case can be handled with a similar member function
operator dynamic_cast T*();

such that a call of dynamic_cast<T*>(foo) is equivalent to
foo.operator dynamic_cast T*();

If no such operator exists, but foo has an operator U*(), then
dynamic_cast<T*>(foo) is equivalent to dynamic_cast<T*>( operatur U*(foo))
as before.  If foo has implicit conversion functions to different pointer
types, the dynamic_cast is ambiguous (and illegal).  And, if no overloaded
operator dynamic_cast is provided, nor any implicit conversions to
pointer, the statement is also illegal.

My smart pointer class above would then contain the following:

        template <class U> operator dynamic_cast Pointer<U> () const
 {
     return Pointer<U> = dynamic_cast<U*> (ptr_);
 }

which is a bit cleaner, and doesn't require different spellings of
dynamic_cast depending on what is being cast....


Possibly, such a thing could be done for reintrepret_cast as well.... :)


Scott "Wait until you see my NEXT language proposal!!!!!" Johnson



--
/--------------------------------------------------------------------------\
|Scott Johnson -- Professional (sometimes) SW Engineer and all-purpose Geek|
|I don't speak for nobody but myself, which everyone else is thankful for  |
\--------------------------------------------------------------------------/


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