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

Subject: Re: [Boost-users] Problem with boost::any?
From: Ulrich Türk (ulit_at_[hidden])
Date: 2009-02-25 04:20:08

Hello all,

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.)?

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.

One quick solution is:
use from any.hpp unsafe_any_cast instead of any_cast
Note that the signature is different; e.g. use

  boost::any b;
  ...
  MyClass* pClass = boost::unsafe_any_cast<MyClass>(&b);
  ...

instead of:

  boost::any b;
  ...
  MyClass class = boost::any_cast<MyClass>(b);
  ...

Read also the comments before unsafe_any_cast in any.hpp; in spite of the
warning that this function is subject to change, it is still in boost 1.38.0 and
it seems to be still used by boost::signal.

> 
> 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?
B) gcc seems to do it since some time for performance reasons
C) IMHO, function pointers and other stuff might not be interesting when just
one wants to get boost::any to work across library borders.

Best regards,
Uli