[cxx-abi-dev] comparing type_infos (was Re: Patch for throw/catch problems)

[Mark Mitchell]

--On Tuesday, August 14, 2001 11:47:45 PM +0100 Jason Merrill 
<jason_merrill at redhat.com> wrote:

>>>>>> "Mark" == Mark Mitchell <mark at codesourcery.com> writes:
>
>> Maybe -- but it is what it says, and it is what people have implemented.
>> I know that there are C++ compilers out there with runtimes that do
>> pointer comparisons now...
>
> Really?  Comparisons of pointers to type_infos, complete with the special
> trickery necessary to handle pointers to incomplete type?  Why, when they
> can just as easily do pointer comparison of the NTBS?

Hmm.  Perhaps I misremember; I will try to find out.  It is true that
it would be no less efficient (and probably more efficient) to do
comparisions of the NTBS instead of the type_info.  I guess Richard
confused me because the original bit on the GCC lists was about changing
from pointer-comparison to strcmp for typeinfo names, and that is an
efficiency hit.

>
>> My opinion is that RTLD_LOCAL is not something we should even try to
>> get right.  It's way too hard.
>
> Yup.

One down.

>
>> Startup cost happens once per program, except for any excess memory
>> used that hangs around.  So, for a long-running application (anything
>> graphical definitely qualifies) this isn't *too* important, and there
>> are techniques (caching, prelinking) that can get around the problem.
>
> And yet it seems to be a significant problem for a significant number of
> people.  I was trying hard to avoid unnecessary dynamic relocations in the
> ABI; clearly I failed.  I think I wasn't paying close enough attention to
> the RTTI stuff.

Certainly a laudable goal.  I do wonder though if a better solution
wouldn't be to improve the dynamic loader; it's certainly possible to
write DLLs in C that have similarly many symbols to relocate.  It's
even more possible in Java or C#.  Not that we shouldn't do what we
can, but heck, GNOME apps written in C don't start up as fast as I'd
like either.

-- 
Mark Mitchell                mark at codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com