This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: type_info::name question

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]