[lug] g++ question: dynamic casts?

[Mr Viggy]

On another note, static casting does no checking what-so-ever.  Dynamic
casting was put into place to do a "smart" cast of sorts.

In other words:  It used to be (and still is, somewhat) when you cast
from a derrived class to a base class, you *loose* information about the
derrived class (basically, the "pointer" is moved down/up in memory to
point to the "top" of the base class).  Now, usually classes don't
retain any information about what they are...  In comes Microsoft's
RTTI, Java's introspection, and dynamic casting.  Now a days, most
compilers retain information about the instance of the class (exactly
what it is; how much memory it takes up; etc).  So, when you do a
dynamic cast from a derrived class down to a base class, you can do then
do a dynamic cast back to the derrived class.  If the pointer you are
trying to cast is not in instance of the class you're casting it to, you
should get a NULL pointer back.

Whew.  With that said, I can easily see there being problems in a
compiler, if the 'dynamic_cast' code, or the "introspection" code was
touched...

Viggy

Ed Hill wrote:
> 
> On Wed, 2002-01-30 at 19:10, Scott A. Herod wrote:
> > Hello,
> >
> >   I know there are some g++ experts around.  I've got code that
> > uses dynamic casts on objects retrieved from a library.  The
> > library was built with gcc 2.95.2.  My code is built with 2.96.
> > The dynamic cast dies; not returns null but dies.  A static cast
> > works and if I build with 2.95.2 the dynamic cast works.
> >
> >   Should I be surprised and upset?
> 
> No, don't be upset.  Thats to be expected.
> 
> While I don't have a URL reference handy, I'm certain that the name
> mangling for RH's so-called "GCC 2.96 release" (which is *not* an
> official GCC release) is (for *some* of the language front-ends that it
> supports) different than that of both the official GCC 2.95.x releases
> and the recent official GCC 3.x series.  The GCC folks do try to
> maintain (or is it guarantee?) name mangling compatibility within a
> release series but will sometimes break it for new release series.
> 
> AFAIK, RH GCC 2.96 was a snapshot of the 3.x development tree and, as
> such, is not C++-name-mangling-compatible with the 2.95.x series and is
> *perhaps* not 100% C++-name-mangling-compatible with the final 3.x
> series, either.  Also I *think* I read that the C name mangling is
> nearly 100% compatible between the 2.95.x, 2.96, and 3.x series.
> 
> Yes, its confusing.  ;-)
> 
> hth,
> Ed
> 
> --
> Edward H. Hill III, PhD
> Post-Doctoral Researcher   |  Email:       ed at eh3.com, ehill at mines.edu
> Division of ESE            |  URL:         http://www.eh3.com
> Colorado School of Mines   |  Phone:       303-273-3483
> Golden, CO  80401          |  Fax:         303-273-3311
> Key fingerprint = 5BDE 4DA1 66BE 4F7B BC17  3A0C 932B 7266 1E76 F123
> 
>   ------------------------------------------------------------------------
>                        Name: signature.asc
>    signature.asc       Type: PGP Armored File (application/x-unknown-content-type-PGP Armored File)
>                 Description: This is a digitally signed message part