Re: RFC: change in std::type_info's equality operator

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Matt Austern <austern@apple.com> writes:

| I sent out a message yesterday suggesting a change in
| std::type_info::operator==.  I didn't get a response, possibly because
| my suggestion was buried in a message that largely talked about other
| things.  (I began with a detailed discussion leading up to why the
| change would be useful for certain purposes.)  So let's try again, and
| this time I'll begin at the beginning.
| 
| Right now, depending on whether or not a certain macro is set when
| libstdc++ is built, t1==t2 is equivalent to one of these two
| expressions:
|   (1) t1.__name == t2.__name, where __name is the address of the
| string representing the type's name.
|   (2) t1.__name == t2.__name || strcmp(t1.__name, t2.__name) == 0.
| 
| The library uses version (1) iff the compiler defines __GXX_WEAK__ to
| be true.
| 
| My proposal: change the library so it unconditionally uses version 2.
| That is, always fall back to string comparison if the address
| comparison
| 
| The disadvantage: it hurts the performance of anything that uses
| typeinfo comparison where negative  comparisons are common.  (I
| suspect that nothing performance-critical uses type_info::operator==.
| I'll drop this proposal if someone shows me otherwise.) The advantage:
| I would like to introduce a feature that has the effect, if users
| specify a particular command line option, of disabling merging of
| typeinfo names across shared libraries.  This mode will not be the
| default.  But the problem is that I can't introduce it at all if
| libstdc++ assumes that names will always be merged.

My opinion is: strongly opposed  to unconditional use version 2.
The reason is precisely the disadvantage you pointed out.
I propose you make the new feature available only for when
__GXX_WEAK__ is not true.  That way, people can choose whether they
prefer the feature with the performance hit or they give up the
feature and retain the performance.  This choice should be made when
the compiler is configured -- to avoid inconsistent translations units
being linked together.

-- Gaby