[Serialization] Non-default constructor and template class
I am attempting to serialize a template class without a default constructor, so I am overriding boost::serialization::save_construct_data(). I'm not sure of the correct syntax to declare that function. The line marked below fails to compile with a "too many template-parameter-lists" error. // Forward declaration of my class template<class Key, class Value, class Hasher> class HashMap; namespace boost { namespace serialization { template<class Archive> template<class Key, class Value, class Hasher> void save_construct_data(Archive &ar, const HashMap< Key, Value, Hasher > *t, const unsigned int file_version); // error here }} Thanks for any help, Kurt
Hi Kurt, you should be able to simply define a private default constructor, if boost::serialization::acess is declared as a friend of your class. There is no need to initialize variables that are in your serialize() function, as Boost.Serialization should set their values after default construction. So in most cases the default constructor may be empty and is trivial to implement, while it can not be called by any external entity (except if it is also declared „friend“). Kind Regards, Beet
Am 15.06.2015 um 21:38 schrieb Mccall, Kurt E. (JSC-EG411) <kurt.e.mccall@nasa.gov>:
I am attempting to serialize a template class without a default constructor, so I am overriding boost::serialization::save_construct_data(). I'm not sure of the correct syntax to declare that function. The line marked below fails to compile with a "too many template-parameter-lists" error.
// Forward declaration of my class template<class Key, class Value, class Hasher> class HashMap;
namespace boost { namespace serialization {
template<class Archive> template<class Key, class Value, class Hasher> void save_construct_data(Archive &ar, const HashMap< Key, Value, Hasher > *t, const unsigned int file_version); // error here }}
Thanks for any help, Kurt
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
you should be able to simply define a private default constructor, if boost::serialization::acess is declared as a friend of your class.
In theory. Current bugs in boost::serialization however then prevent the use in a container, for example serializing a std::set<T> where T has a private default constructor.
On 6/16/15 1:19 PM, Philipp Münzel wrote:
you should be able to simply define a private default constructor, if boost::serialization::acess is declared as a friend of your class.
In theory. Current bugs in boost::serialization however then prevent the use in a container, for example serializing a std::set<T> where T has a private default constructor.
lol - that's not a bug - that's the way it's always been. And it has nothing to do with serialization of containers per se. The whole concept of "private function" conflicts with the concept of calling functions from outside the class. So either one violates the contract implied by private and implements the constructor outside the class or one respects the C++ syntax and doesn't try to get around it. Robert Ramey
Not so much LOL. I was referring to this bug: https://svn.boost.org/trac/boost/ticket/11343 which seems to be fixed now on master. On 16.06.2015 18:01, Robert Ramey wrote:
On 6/16/15 1:19 PM, Philipp Münzel wrote:
you should be able to simply define a private default constructor, if boost::serialization::acess is declared as a friend of your class.
In theory. Current bugs in boost::serialization however then prevent the use in a container, for example serializing a std::set<T> where T has a private default constructor.
lol - that's not a bug - that's the way it's always been. And it has nothing to do with serialization of containers per se. The whole concept of "private function" conflicts with the concept of calling functions from outside the class. So either one violates the contract implied by private and implements the constructor outside the class or one respects the C++ syntax and doesn't try to get around it.
Robert Ramey
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (7)
-
Mccall, Kurt E. (JSC-EG411) -
Philipp Münzel -
Robert Ramey -
Rüdiger Berlich