troy d. straszheim wrote:
Robert Ramey wrote:
troy d. straszheim wrote:
Hey,
Here's an autoregistering serializable any, I think it qualifies as hacky and suboptimal. Of course the typeid(T).name() strings aren't portable,
if you use serialization/extended_type_info, instead of typeid(T)name() you can use the strings used by BOOST_CLASS_EXPORT which are portable.
Hm, I don't quite follow...
BOOST_CLASS_EXPORT(T)
just associates "T" with typename T. Maybe one could cobble together something like
BOOST_ANY_EXPORT(U)
which would expand to something like
BOOST_CLASS_EXPORT_GUID(boost::any::holder<U>, "boost_any_holder_" BOOST_PP_STRINGIZE(U))
Something like that
But one of the OP's requirements was that a list of instantiations of anys not be necessary. Do we want to toss that requirement in favor of moving closer to something that could actually go into the library... or what am I missing?
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 Robert Ramey PS:what does OP stand for?