Re: unloading plugins (i.e. shared objects) nearly impossible!
davidbaraff@gmail.com wrote:
[...]
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
conformant.
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
necessary destructors.
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! ]