libcxx: support typeids across DLL boundary

[Reid Kleckner]

On Fri, Nov 22, 2013 at 3:08 PM, Yaron Keren <yaron.keren at gmail.com> wrote:

> MSVC is confused by the same-named source file!
> If the code is split into  t1.cpp:
>

Oh, right, I discovered that yesterday.  It's really annoying, considering
that my standard testing methodology is to use the same file compiled
twice.  :(


> However, your point IS valid, since when the actual names are printed
> (names which will be used in the strcmp):
>
>   printf("tu1().name: %s\n", tu1().name());
>   printf("tu2().name: %s\n", tu2().name());
>
> with MSVC we get
>
> tu1() == tu2(): 0
> tu1().name: struct `anonymous namespace'::Foo
> tu2().name: struct `anonymous namespace'::Foo
>
> and with gcc:
>
> tu1() == tu2(): 0
> tu1().name: *N12_GLOBAL__N_13FooE
> tu2().name: *N12_GLOBAL__N_13FooE
>
> So when comparing type ids only, we'll miss exceptions from DLLs, while if
> we compare type names as well we may catch a same-named class coming from
> the same namespace even it's actually something different.
>
> Given only these two options (maybe there is a better solution?), I'd
> still go with the first, since many C++ DLL libraries throw exceptions
> which *must* be caught, else the library is not usable. This is a
> showstopper.
>
> OTOH, same-named classes - in the same namespace - in different TU are
> probably uncommon and throwing them around where they might be confused is
> probably even less common.
>

MSDN says MSVC lets you get at the mangled/decorated name with .raw_name(),
and this should be good enough, barring people like me recompiling the same
source file with different macros.  :)

I don't see how to fix this for gcc, though, if they don't surface a unique
mangled name for types in anonymous namespaces.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131122/5c0ec451/attachment.html>