[serialization] problems implementing free-standing functions
Hi, I'm having some annoying problems when implementing serialization for the attached class. Basically I define boost::serialization::load()/save(). I do just like done in e.g. boost.ptr_container, so I'm really confused about what's going on here. From the error message it looks like the free-standing functions are not found. Any help will be greatly appreciated. Thanks -Thorsten
Try removing the code from the "detail" namespace. If this works, look at the definition of split_free to see why. You might want to use you're own definition of split free. Robert Ramey
Robert Ramey skrev:
Try removing the code from the "detail" namespace.
I renamed the functions, so they are not called load(). But it did not help. The compiler gives me this error: d:\boost\trunk\boost/serialization/access.hpp(109) : error C2039: 'serialize' : is not a member of 'boost::auto_buffer<T>' Why does the library look for that function? -Thorsten
Thorsten Ottosen wrote:
Robert Ramey skrev:
Try removing the code from the "detail" namespace.
I renamed the functions, so they are not called load(). But it did not help.
The compiler gives me this error:
d:\boost\trunk\boost/serialization/access.hpp(109) : error C2039: 'serialize' : is not a member of 'boost::auto_buffer<T>'
Why does the library look for that function?
Your include guard is broken: #ifdef BOOST_UTILITY_AUTO_BUFFER_SERIZLIZATION_HPP_01_03_2009 :) -- Daniel Wallin BoostPro Computing http://www.boostpro.com
Daniel Wallin skrev:
Thorsten Ottosen wrote:
Robert Ramey skrev:
Try removing the code from the "detail" namespace. I renamed the functions, so they are not called load(). But it did not help.
The compiler gives me this error:
d:\boost\trunk\boost/serialization/access.hpp(109) : error C2039: 'serialize' : is not a member of 'boost::auto_buffer<T>'
Why does the library look for that function?
Your include guard is broken:
#ifdef BOOST_UTILITY_AUTO_BUFFER_SERIZLIZATION_HPP_01_03_2009
:)
Doh!!!! *"#"54¤#"####""¤%%%#!"!!? Thanks! Robert, I also tried looking in the docs for this, but I did not find a description there: I want to take advantage of an optimized ways to serialize the underlying array of the auto_buffer (memcpy or similar). I assume there is already code to do that. Can it be reused for my class? If so, how? Thanks in advance -Thorsten
Mathias is the expert on this. The documentation describes how to add specify serialization attributes (is_bitwise_serialzable?) to your types so that higher speed algorithims will be used if possible. Robert Ramey
Thanks!
Robert, I also tried looking in the docs for this, but I did not find a description there: I want to take advantage of an optimized ways to serialize the underlying array of the auto_buffer (memcpy or similar). I assume there is already code to do that. Can it be reused for my class? If so, how?
Thanks in advance
-Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Move serialize out of the detail namespace. replace ... template<class Archive, class T, unsigned N, class Allocator> inline void serialize(Archive& ar, auto_buffer<T, N, Allocator>& c, const unsigned int version) { boost::serialization::split_free(ar, c, version); } } with ... } template<class Archive, class T, unsigned N, class Allocator> inline void serialize(Archive& ar, auto_buffer<T, N, Allocator>& c, const unsigned int version) { boost::serialization::split_free(ar, c, version); } Robert Ramey
Hi Robert, Robert Ramey skrev:
Move serialize out of the detail namespace.
replace ... template<class Archive, class T, unsigned N, class Allocator> inline void serialize(Archive& ar, auto_buffer<T, N, Allocator>& c, const unsigned int version) { boost::serialization::split_free(ar, c, version); } }
with
... } template<class Archive, class T, unsigned N, class Allocator> inline void serialize(Archive& ar, auto_buffer<T, N, Allocator>& c, const unsigned int version) { boost::serialization::split_free(ar, c, version); }
What is this the answer for? Does it answer how I make use of the optmized array code already in Boost.Serialization? -Thorsten PS. I've atatched the code that know actually compiles.
Hi Robert, FWIW, I still stumple into the problem that you can't serialize a non-const object. This happens even for something as simple as serializing an int. I thought you had replaced this behavior with a sort of warning instead? If I would be to use the library for teaching or otherwise, I would just be littering my code with << ... ( as_const(x) ) and if I do so, I probably don't get any help to track down the problems you claim this prevents. Is it not posssible to turn this feature into a debugging aid, rather than something that is enabled by default? I'm thinking that the cost of the current strategy very much out-weights its benefits :-(. -Thorsten
From: Thorsten Ottosen [mailto:thorsten.ottosen@dezide.com]
From: Thorsten Ottosen [mailto:thorsten.ottosen@dezide.com] Sent: Monday, March 02, 2009 10:35 AM To: boost@lists.boost.org Cc: Robert Ramey Subject: Re: [serialization] problems implementing free-standing functions
Hi Robert,
FWIW, I still stumple into the problem that you can't serialize a non-const object. This happens even for something as simple as serializing an int.
I thought you had replaced this behavior with a sort of warning instead?
*** I believe that I did changed it from BOOST_STATIC_ERROR TO BOOST_STATIC_WARNING in the latest released version. Note that the implemenation BOOST_STATIC_WARNING is non-portable and for at least one platform I couldn't implement it so I left it as a no-op.
If I would be to use the library for teaching or otherwise, I would just be littering my code with
<< ... ( as_const(x) )
and if I do so, I probably don't get any help to track down the problems you claim this prevents.
*** Well, you can't have it both ways. Either the library flags the situation with (now) warning or it doesn't. I realize that my view on the subject is not universally held, but I'm more firmly convinced than ever that the need to pepper one's code with const_cast is an indication of problems in the design and/or implemenation of the code.
Is it not posssible to turn this feature into a debugging aid, rather than something that is enabled by default? I'm thinking that the cost of the current strategy very much out-weights its benefits :-( .
*** that was my intention when I changed it from ERROR to WARNING.
Thorsten Ottosen skrev:
From: Thorsten Ottosen [mailto:thorsten.ottosen@dezide.com]
Is it not posssible to turn this feature into a debugging aid, rather than something that is enabled by default? I'm thinking that the cost of the current strategy very much out-weights its benefits :-( .
*** that was my intention when I changed it from ERROR to WARNING.
Here's my error: d:\boost\trunk\boost/utility/serialize_auto_buffer.hpp(62) : error C2664: 'boost ::serialization::make_nvp' : cannot convert parameter 2 from 'unsigned int' to ' unsigned int &' Produced by this line: ar << boost::serialization::make_nvp( "count", c.capacity() ); Why do I need to store the object locally first? I'm using visual C++ 9 SP1. -Thorsten
Why do I need to store the object locally first?
Of course the easy answer is that the make_nvp takes a reference and the compiler flags an error the conversion of an temporary item on the stack as an error. But of course you knew that. The real question is, "Why does make_nvp (and other wrappers) take only references rather than copying real values". Here a couple of reasons. a) All parameters in the serialization library are passed by reference. This is necessary to support tracking for those situations which require it. It would be confusing if support of tracking were a hidden side effect of how an argument has been passed. b) make_nvp is a wrapper. The concept of a wrapper is to add some extra "sauce" (in this case, the external name of the data item") while leaving original operations the same. This is the case with all wrappers. That is, a wrapper doesn't change things, it just adds something. This permits one to keep in his brain what is really going on. Also it permits one to nest wrappers to any resonable depth. c) passing by reference is going to be more efficient for larger structures. d) not all structures have copy constructors FWIW, Lately, I've had occasion to consider this question in more depth and can see how elaborating this issue might make the serialization library useful in new domains. However this is outside of the scope of this discussion. Robert Ramey Thorsten Ottosen wrote:
Thorsten Ottosen skrev:
From: Thorsten Ottosen [mailto:thorsten.ottosen@dezide.com]
Is it not posssible to turn this feature into a debugging aid, rather than something that is enabled by default? I'm thinking that the cost of the current strategy very much out-weights its benefits :-( .
*** that was my intention when I changed it from ERROR to WARNING.
Here's my error:
d:\boost\trunk\boost/utility/serialize_auto_buffer.hpp(62) : error C2664: 'boost
serialization::make_nvp' : cannot convert parameter 2 from 'unsigned int' to ' unsigned int &'
Produced by this line:
ar << boost::serialization::make_nvp( "count", c.capacity() );
Why do I need to store the object locally first?
I'm using visual C++ 9 SP1.
-Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey skrev:
Why do I need to store the object locally first?
Of course the easy answer is that the make_nvp takes a reference and the compiler flags an error the conversion of an temporary item on the stack as an error. But of course you knew that.
The real question is, "Why does make_nvp (and other wrappers) take only references rather than copying real values". Here a couple of reasons.
a) All parameters in the serialization library are passed by reference. This is necessary to support tracking for those situations which require it. It would be confusing if support of tracking were a hidden side effect of how an argument has been passed.
b) make_nvp is a wrapper. The concept of a wrapper is to add some extra "sauce" (in this case, the external name of the data item") while leaving original operations the same. This is the case with all wrappers. That is, a wrapper doesn't change things, it just adds something. This permits one to keep in his brain what is really going on. Also it permits one to nest wrappers to any resonable depth.
c) passing by reference is going to be more efficient for larger structures.
d) not all structures have copy constructors
FWIW, Lately, I've had occasion to consider this question in more depth and can see how elaborating this issue might make the serialization library useful in new domains. However this is outside of the scope of this discussion.
After thinking a little about it I guess it is quite ok, since we don't want to serialize temporary objects by accident. I can't get the error that I though I was getting about not being able to serialize non-const objects. I guess it was just the above error all. Thanks -Thorsten
participants (3)
-
Daniel Wallin -
Robert Ramey -
Thorsten Ottosen