Re: [Boost-users] Problem with boost::any?

Subject: Re: [Boost-users] Problem with boost::any?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-02-25 19:38:02

On Wed, Feb 25, 2009 at 1:20 AM, Ulrich Türk <ulit_at_[hidden]> wrote:
> Emil Dotchevski <emildotchevski <at> gmail.com> writes:
>> Isn't this a problem of using the incorrect visibility options and/or
>> dlopen flags? My plugin system (including its use of std::type_info,
>> and including dynamic unloading) works fine on Windows and LINUX, so
>> unless you're hitting some kind of version-specific bug, you might be
>> doing something wrong.
>
> Could you please describe shortly, if your plugins are compiled with specific
> visibility options and how you load them (dlopen flags e.g.)?

Yes, I'm using RTLD_GLOBAL.

> I also encountered the reported problem.
> My plugin system here uses the dlopen flag RTLD_LOCAL in order keep plugins
> separated. Some other support libraries for loading shared objects e.g. libtldl
> might not support specifying this flag to RTLD_GLOBAL.

If you want certain symbols in a .so to not be visible, you can make
them invisible when you build the .so; dlopen would still see
everything else, including the important compiler-generated stuff like
type_info objects and vtables. Reducing the visible symbols in a .so
could also reduce its size.

>> I am strongly against using string comparisons for std::type_info
>> objects because A) they might not work, B) if this was the right thing
>> to do the compiler would be doing it that way (as MSVC does), and C)
>> it would do nothing to solve the more general problem, which has to do
>> with symbol visibility. If your std::type_info comparison is broken,
>> then comparing function pointers and other compiler-generated objects
>> is broken too.
>
> A) is it due to different name mangling?

A) Is due to the C++ standard not guaranteeing you anything about what
.name() returns. A standard-conforming compiler could strip out all
names and return "n00b" for every type name.

> B) gcc seems to do it since some time for performance reasons

All I'm saying is that operator== is the right way to compare
std::type_info objects. I don't know if the only motivation for the
exact behavior of operator== is performance, but I don't feel
qualified to suggest to the GCC team to change it (which would be the
right "fix", assuming there is a problem to fix.)

> C) IMHO, function pointers and other stuff might not be interesting when just
> one wants to get boost::any to work across library borders.

What about virtual function table pointers? What about the rest of the
RTTI system? Would dynamic_cast<void *> work correctly? Would
dynamic_cast in general work correctly? What about exception handling?

Basically, I'm assuming that given the behavior of
type_info::operator==, GCC relies on the same symbols coming from
different modules to resolve to the same address, which is the
RTLD_GLOBAL behavior (by the way, typically it isn't a problem to use
RTLD_GLOBAL because it is close to the behavior you get when linking
statically.)

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode