Re: unloading plugins (i.e. shared objects) nearly impossible!
If STL happened to use virtual functions (which it doesn't)
You don't know this. Stepanov didn't believe in virtual
functions, and most implementations today still derive from his
original implementation. But in a context where memory is
tight, and you can't afford code duplication, a base class
factoring out the common behavior, and using virtual functions
for the type specific parts, could be a very reasonable
implementation. Such an implementation would be perfectly
we'd be saying, "well, of course returning a vector<T> from a
plugin isn't safe, if the main program holds onto it."
Not really. The problem with boost::any is that your main
program doesn't know about the types which it hides. Even if
vector<T> used virtual functions, if you had a vector<int>
object on the stack in your code, your code would contain the
The problem you encountered was because you didn't have an
any<T> anywhere. It was because you didn't instantiate any
template for any in your code.
The problem only occurs when the implementation uses hidden
polymorphic types. And has nothing to do with templates: a more
primitive version of any, which only supported basic types, and
had hand written handlers for each type (rather a stupid way to
do it, but) would cause the same problem.
I think it's a documentation problem, a restriction that should
be documented in boost::any. And I doubt that it will actually
affect that many things in practice.
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]