[Serialization] Serialization of a derived template class inheriting from a none template base
Hi, I'm in the process of trying to get boost::any serializable, and it's quite tricky, especially considered my very limited experience with boost::serialize. I googled around and found an old discussion on this very list, and while interesting no resolution seemed to be found which satisfied all the criteria for being commited boost. However, since I'm not as picky with data portability, the solution hinted at in: http://lists.boost.org/boost-users/2005/09/14266.php seems very interesting. The only problem is that I can't see how it would be implemented to solve this problem. It needs to be within the definition of the class to be able for the typename to be in scoop, but since the macro seems to expand to a definition to be placed in the boost namespace I can't seem to get it to play nice. Any solution which lets me automagicaly serialize boost::any which contains serializable types, even if intrusive, would be extremely welcomed.
Hi,
I'm in the process of trying to get boost::any serializable, and it's quite tricky, especially considered my very limited experience with boost::serialize. I googled around and found an old discussion on this very list, and while interesting no resolution seemed to be found which satisfied all the criteria for being commited boost. However, since I'm not as picky with data portability, the solution hinted at in: http://lists.boost.org/boost-users/2005/09/14266.php seems very interesting. The only problem is that I can't see how it would be implemented to solve this problem.
It needs to be within the definition of the class to be able for the typename to be in scoop, but since the macro seems to expand to a definition to be placed in the boost namespace I can't seem to get it to play nice.
Any solution which lets me automagicaly serialize boost::any which contains serializable types, even if intrusive, would be extremely welcomed.
Okay, not much action there. I'll try to paraphrase myself. Is there any work being done on trying to solve the underlying problem? I know there's other use cases where one usually inherits from a base class when doing template classes to be able to store pointers. I'd think it would be possible to solve this with making serialize virtual, but then you'd have to specialize it for every archive, and well, down that road lies mostly ruin. I'd love to fix this myself, and I do in fact have a couple tricks going which at least is better than virtual. Basically having a static member which one initialize through a function call which registers the type. The only problem is that the serialization library isn't really for the faint of heart, there's a lot of trickery pokery. And I have no experience with either mpi or template meta programming, so it's sadly kind of a large task to tackle for me. Sorry for being a nuisance but I really want to use boost::serialize, and this is a total deal breaker for me. I understand that it's a hard problem, and I understand that there's most likely no ideal solution found. I'm looking for something which while sub optimal, is as good as it currently gets, and is better than making serialize virtual and having to specialize it for all possible archive types. // Sebastian Karlsson
I don't know if this helps, but you might want to take a look at the implementation of serialization of variant. Robert Ramey Sebastian.Karlsson@mmorpgs.org wrote:
Hi,
I'm in the process of trying to get boost::any serializable, and it's quite tricky, especially considered my very limited experience with boost::serialize. I googled around and found an old discussion on this very list, and while interesting no resolution seemed to be found which satisfied all the criteria for being commited boost. However, since I'm not as picky with data portability, the solution hinted at in: http://lists.boost.org/boost-users/2005/09/14266.php seems very interesting. The only problem is that I can't see how it would be implemented to solve this problem.
It needs to be within the definition of the class to be able for the typename to be in scoop, but since the macro seems to expand to a definition to be placed in the boost namespace I can't seem to get it to play nice.
Any solution which lets me automagicaly serialize boost::any which contains serializable types, even if intrusive, would be extremely welcomed.
Okay, not much action there. I'll try to paraphrase myself. Is there any work being done on trying to solve the underlying problem? I know there's other use cases where one usually inherits from a base class when doing template classes to be able to store pointers. I'd think it would be possible to solve this with making serialize virtual, but then you'd have to specialize it for every archive, and well, down that road lies mostly ruin.
I'd love to fix this myself, and I do in fact have a couple tricks going which at least is better than virtual. Basically having a static member which one initialize through a function call which registers the type. The only problem is that the serialization library isn't really for the faint of heart, there's a lot of trickery pokery. And I have no experience with either mpi or template meta programming, so it's sadly kind of a large task to tackle for me.
Sorry for being a nuisance but I really want to use boost::serialize, and this is a total deal breaker for me. I understand that it's a hard problem, and I understand that there's most likely no ideal solution found. I'm looking for something which while sub optimal, is as good as it currently gets, and is better than making serialize virtual and having to specialize it for all possible archive types.
// Sebastian Karlsson
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, and the implementation gets a little intimate with the mechanics of registration, but it works... You could make this less intrusive, I suppose, but without the venerable #define private public technique (still one of my all time favorite hacks) I don't think you're going to get it completely nonintrusive. -t Robert Ramey wrote:
I don't know if this helps, but you might want to take a look at the implementation of serialization of variant.
Robert Ramey
Sebastian.Karlsson@mmorpgs.org wrote:
Hi,
I'm in the process of trying to get boost::any serializable, and it's quite tricky, especially considered my very limited experience with boost::serialize. I googled around and found an old discussion on this very list, and while interesting no resolution seemed to be found which satisfied all the criteria for being commited boost. However, since I'm not as picky with data portability, the solution hinted at in: http://lists.boost.org/boost-users/2005/09/14266.php seems very interesting. The only problem is that I can't see how it would be implemented to solve this problem.
It needs to be within the definition of the class to be able for the typename to be in scoop, but since the macro seems to expand to a definition to be placed in the boost namespace I can't seem to get it to play nice.
Any solution which lets me automagicaly serialize boost::any which contains serializable types, even if intrusive, would be extremely welcomed. Okay, not much action there. I'll try to paraphrase myself. Is there any work being done on trying to solve the underlying problem? I know there's other use cases where one usually inherits from a base class when doing template classes to be able to store pointers. I'd think it would be possible to solve this with making serialize virtual, but then you'd have to specialize it for every archive, and well, down that road lies mostly ruin.
I'd love to fix this myself, and I do in fact have a couple tricks going which at least is better than virtual. Basically having a static member which one initialize through a function call which registers the type. The only problem is that the serialization library isn't really for the faint of heart, there's a lot of trickery pokery. And I have no experience with either mpi or template meta programming, so it's sadly kind of a large task to tackle for me.
Sorry for being a nuisance but I really want to use boost::serialize, and this is a total deal breaker for me. I understand that it's a hard problem, and I understand that there's most likely no ideal solution found. I'm looking for something which while sub optimal, is as good as it currently gets, and is better than making serialize virtual and having to specialize it for all possible archive types.
// Sebastian Karlsson
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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.
and the implementation gets a little intimate with the mechanics of registration, but it works... You could make this less intrusive, I suppose, but without the venerable
#define private public
technique (still one of my all time favorite hacks) I don't think you're going to get it completely nonintrusive.
It looks like a good start. Perhaps a "little something" should be added to the public interface of boost::any to support serialization. Robert Ramey
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)) 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? -t
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?
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
troy d. straszheim:
OK, I wasn't missing anything. The Original Poster (OP) wanted to avoid this 'predeclaration', I thought we were going that direction, got confused.
I don't think that it's possible to avoid the predeclaration in general when deserializing. Toy examples that serialize and then deserialize in the same program will obviously work.
For a full portability of strings I would convert them into UTF-8, this solves any endianess issue and different local code pages issue. Same for file format. -----Messaggio originale----- Da: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] Per conto di troy d. straszheim Inviato: sabato 9 agosto 2008 19.56 A: boost-users@lists.boost.org Oggetto: [Boost-users] serializable any 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, and the implementation gets a little intimate with the mechanics of registration, but it works... You could make this less intrusive, I suppose, but without the venerable #define private public technique (still one of my all time favorite hacks) I don't think you're going to get it completely nonintrusive. -t ...
serialization library already does that. Robert Ramey Andrea Denzler wrote:
For a full portability of strings I would convert them into UTF-8, this solves any endianess issue and different local code pages issue. Same for file format.
-----Messaggio originale----- Da: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] Per conto di troy d. straszheim Inviato: sabato 9 agosto 2008 19.56 A: boost-users@lists.boost.org Oggetto: [Boost-users] serializable any
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, and the implementation gets a little intimate with the mechanics of registration, but it works... You could make this less intrusive, I suppose, but without the venerable
#define private public
technique (still one of my all time favorite hacks) I don't think you're going to get it completely nonintrusive.
-t ...
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, and the implementation gets a little intimate with the mechanics of registration, but it works... You could make this less intrusive, I suppose, but without the venerable
#define private public
technique (still one of my all time favorite hacks) I don't think you're going to get it completely nonintrusive.
-t
Thanks! That was certainly better than my current solution :) // Sebastian Karlsson
participants (5)
-
Andrea Denzler -
Peter Dimov -
Robert Ramey -
Sebastian.Karlsson＠mmorpgs.org -
troy d. straszheim