Robert Ramey wrote:
Hmm - I don't think you're missing anything. You're right, if you use typeid() you don't have to "predeclare" anything - but it can't be used to create portable archives. That's the whole justification for creating BOOST_CLASS_EXPORT...
Basically, either one has to do one of the following:
a) except the fact that in some sense one has to "declare" any<U> as being "exportable" b) eliminated the heretofore enforced requirement that archives be portable.
So far we've done a) - hence shared_ptr serialization has a macro (whose name I forget) to handle a situation. Leveraging on this concept - and diminishing the proliferation of special cases would argue for something similer in other special cases - like boost::any
OK, I wasn't missing anything. The Original Poster (OP) wanted to avoid this 'predeclaration', I thought we were going that direction, got confused. So you'd need to expose the internals of any to the world, as the export macro has to expand to something that refers to boost::any::holder<T>, which is private. Friending boost::serialization::access any won't do it, as boost::serialization::access isn't the one doing the registration, and the expansion of the export macro will appear in some arbitrary location chosen by the user. So for export of boost::any that holds type V, you'd need ::boost::serialization::any_export<V> where any_export is *also* a friend of boost::any, and it registers any::holder<V> with serialization::detail::guid_initializer<any::holder<V> >. or something like that. Maybe one can make this work just by forward declaring and friending boost::serialization::access and boost::serialization::any_exporter inside boost::any. Dunno, maybe I'll try it. It'd be good to know if those modifications would be acceptable first. -t