This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: type_info::name question
- To: ncm at nospam dot cantrip dot org
- Subject: Re: type_info::name question
- From: Martin von Loewis <martin at mira dot isdn dot cs dot tu-berlin dot de>
- Date: Sat, 19 Sep 1998 19:51:26 +0200
- CC: egcs at cygnus dot com
- References: <35FFEE86.F7625EA6@nospam.cantrip.org>, <199809172030.WAA01914.cygnus.egcs@mira.isdn.cs.tu-berlin.de> <3602EA79.936D5EAC@nospam.cantrip.org>
> uses it won't be conforming. With member name() there is at least
> a chance, if the compiler implementors co-operate.
This is what makes this approach particularly bad. Using the standard
method will make it compile, yet it works in an implementation-defined
way. Most users won't be aware of these details, and run into problems
without being warned. If you use an extension, you *know* you need to
consider this code when using a different compiler.
Using an additional method might not be good, because you'd have to
use macros to replace them on a different compiler. A global function
char* __mangle(type_info&);
might be better; one could then implement this in different ways
depending on the compiler.
> This is not to say that GNU extensions in this area wouldn't be
> useful (e.g. __mangle(), __squangle(), __corba()). It is only
> to say that the name() member should be settable at compile time
> to be synonymous with any of the GNU extensions.
I'm not against g++ giving some additional guarantees about the string
returned by name(); I just think it is bad advise to use name() as
long as there no guarantees (unless it is used for debugging).
For example, g++ could warn if name is called, while the user did not
request specific semantics for it.
Regards,
Martin