[lug] g++ question: dynamic casts?

[D. Stimits]

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

static_cast does do some checking against void pointers, so static_cast
will fail in some cases where the C style cast works. If you want true C
style cast, then reinterpret_cast was designed for that. On the other
hand, I've found with some of the older compilers (not too old, but a
bit older g++), reinterpret_cast *is* doing some checking in the case of
void pointers. And the degree that static_cast does or does not complain
seems to change depending on compiler version.

On the other hand, if mangling schemes are different between two
compilers, and you link 2.96 code with 2.95.2, I suspect it is a time
bomb waiting to go off. The fact that dynamic_cast fails probably does
mean it isn't handling inheritance the same way. But, perhaps the linker
itself understands this somewhat? There might be a difference between
using the system linker and dlopen(). C doesn't do name mangling, so it
is a different story, but I'd be very wary about mixing code compiled
with two separate mangling schemes. Perhaps they are close enough to
work in some or many cases...it is almost guaranteed to fail or act
strange in at least one or two situations. The safe thing would be to
get the library source and recompile it with the 2.96 compiler.

D. Stimits, stimits at idcomm.com

> 
> 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
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug