Re: type_info::name question

[Nathan Myers <ncm at nospam dot cantrip dot org>]

Martin von Loewis wrote:
> 
> > Sorry, I don't agree.  The industrial use of type_info::name is to
> > generate a key to represent a type for streamed object representations.
> 
> Unfortunately, this is a non-portable use. The standard does not
> guarantee any properties of the string returned, not even uniqueness
> in some sense.  ...  Telling people they
> can use type_info::name for this application is bad advice.

The definition is left "implementation-defined" in the standard 
_specifically_ to allow implementers to define something useful.  
The intent was to allow users to write code that is portable 
among those implementations which support the features required.  
One thing guaranteed about a GNU-only extension is that code that 
uses it won't be conforming.  With member name() there is at least 
a chance, if the compiler implementors co-operate.

That is, at least a program will be able to talk to another
program compiled with the same-version compiler, if the feature 
is implemented meaningfully at all; maybe with programs compiled
other versions of the same compiler, if the implementer has 
documented the format; and possibly with code compiled with 
some other compilers, if the definition references another 
standard.  The last is not possible with a GNU-only extension.

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.

Nathan Myers
ncm@cantrip.org