RE: [Cppunit-devel] config.h changes committed

[Bastiaan B. <bas...@li...>]

> -----Oorspronkelijk bericht-----
> Van: Baptiste Lepilleur [mailto:bl...@cl...]
> Verzonden: Monday, June 18, 2001 9:53 PM
> Aan: cpp...@li...
> Onderwerp: Re: [Cppunit-devel] config.h changes committed
> 
> 
> ----- Original Message -----
> From: "Steve M. Robbins" <ste...@vi...>
> To: <cpp...@li...>
> Sent: Monday, June 18, 2001 7:20 PM
> Subject: Re: [Cppunit-devel] config.h changes committed
> 
> 
> > On Mon, Jun 18, 2001 at 05:16:36PM +0200, Baptiste Lepilleur wrote:
> > > Quoting "Steve M. Robbins" <ste...@vi...>:
> > >   OK. I did know what's was behind the RTTI thingy (kinda 
> strange, I did
> not
> > > though that you could have the type_info without dynamic_cast).
> >
> > All I'm saying is that the macro defines HAVE_RTTI based on the
> > presence of typeid().  You are probably right that dynamic_cast is
> > present if typeid() is present; I don't know much about 
> RTTI.  It may
> > be that the reverse is not true, however.  My instinct is to assume
> > dynamic_cast is available, if needed, (and without checking) until
> > someone tells us otherwise.
>     OK.
> 

Yes, AFAIK, having typeid() equals having dynamic_cast equals having
HAVE_RTTI. 

> > >   Well, I propose to keep USE_TYPEINFO.
> > >
> > >   Our USE_TYPEINFO could be defined as: you have typeinfo, and the
> name()
> > > methode return a human readable name (that last one can't 
> be tested by a
> > > machine unfortunately). So it's a stronger requirement 
> than HAVE_RTTI.
> >

Yes, I was mistaken in my previous mail. USE_TYPEINFO needs more than
HAVE_RTTI. So, let's keep it.

> > It's true that GCC can produce an ungainly type name like
> >
> >
> t23Triangle_3_Plane_3_test1ZQ24CGALt11Homogeneous2ZQ24CGAL4Gmp
> zZQ24CGALt8Quo
> tient1ZQ24CGAL4Gmpz.point_intersection
>   Yuck!!! Baastian, did you look up an explanation for this 
> from the gcc
> folks ? (name are still useful for debugging)
> 

I couldn't find any reasoning for the current g++ implementation in the
mailing list archive and I haven't contacted the maintainers yet. Now that
they have released GCC 3.0, they'll probably have more time for new features
/ functional improvements, so I'll try soon.

> > so the idea of perhaps not using that name has merit.  In that case,
> > the symbol might be more appropriately-named USE_TYPEINFO_NAME.  You
> > may still wish to use type_info structures to test equality of
> > types.
>     I agree, that name reveal the intention better.
> 

Agreed.

> >
> > I'll have to think about this.  There seem to be relatively few uses
> > of using type_info::name() at present, and I'm puzzled by 
> some of them.
> >
> > For example, what is the purpose of class 
> CppUnit::TypeInfoHelper?  Is
> > there some advantage to using a class rather than a simple function
> > CppUnit::getClassName() ?
>    Yes. I though that the class would grow, but it did not. 
> Actually, isn't
> that the only use of name() ?
> 
>     Baptiste.

Well, for debuggers the mangled name may be more interesting. But the
standard does not document any use for the name() method, so we can only
guess.

Bastiaan