[ptr_container] feature request: BOOST_PTR_CONTAINER_NO_SERIALIZATION
As of version 1.34, Boost.PtrContainer supports serialization as defined by Boost.Serialization. Now I'd like to propose a switch to disable this feature. The attached patch adds checks if BOOST_PTR_CONTAINER_NO_SERIALZATION is defined around the serialization related code blocks and enables/disables serialization support. It's not that I don't like serialization support but on a Debian system you have to install libboost-serialization-dev and libboost-serialization1.34.0 just to use Boost.PtrContainer. The patch was created against CVS HEAD but I'd gladly provide a patch against 1.34 if it finds any interest. Regards, Sebastian Index: ptr_array.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/ptr_container/ptr_array.hpp,v retrieving revision 1.9 diff -u -r1.9 ptr_array.hpp --- ptr_array.hpp 16 Feb 2006 23:38:36 -0000 1.9 +++ ptr_array.hpp 28 May 2007 13:35:29 -0000 @@ -190,6 +190,7 @@ return this->c_private()[idx] == 0; } +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION public: // serialization template< class Archive > @@ -214,7 +215,7 @@ } BOOST_SERIALIZATION_SPLIT_MEMBER() - +#endif }; ////////////////////////////////////////////////////////////////////////////// Index: ptr_map_adapter.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/ptr_container/ptr_map_adapter.hpp,v retrieving revision 1.26 diff -u -r1.26 ptr_map_adapter.hpp --- ptr_map_adapter.hpp 8 Mar 2006 23:16:00 -0000 1.26 +++ ptr_map_adapter.hpp 28 May 2007 13:36:09 -0000 @@ -291,6 +291,7 @@ return replace( where, x.release() ); } +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION public: // serialization template< class Archive > @@ -305,6 +306,7 @@ ar & ptr_container_detail::serialize_as_const( i->second ); } } +#endif }; } // ptr_container_detail @@ -472,6 +474,7 @@ return transfer( from.begin(), from.end(), from ); } +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION public: // serialization template< class Archive > @@ -493,7 +496,7 @@ } BOOST_SERIALIZATION_SPLIT_MEMBER() - +#endif }; ///////////////////////////////////////////////////////////////////////// @@ -647,6 +650,7 @@ BOOST_ASSERT( from.empty() ); } +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION public: // serialization template< class Archive > @@ -668,7 +672,7 @@ } BOOST_SERIALIZATION_SPLIT_MEMBER() - +#endif }; template< class I, class F, class S > Index: ptr_vector.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/ptr_container/ptr_vector.hpp,v retrieving revision 1.10 diff -u -r1.10 ptr_vector.hpp --- ptr_vector.hpp 18 Feb 2006 01:41:14 -0000 1.10 +++ ptr_vector.hpp 28 May 2007 13:35:09 -0000 @@ -53,6 +53,7 @@ this->c_private().reserve( n ); } +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION public: // serialization template< class Archive > @@ -66,7 +67,7 @@ } BOOST_SERIALIZATION_SPLIT_MEMBER() - +#endif }; ////////////////////////////////////////////////////////////////////////////// Index: detail/reversible_ptr_container.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/ptr_container/detail/reversible_ptr_container.hpp,v retrieving revision 1.24 diff -u -r1.24 reversible_ptr_container.hpp --- detail/reversible_ptr_container.hpp 6 Mar 2006 20:09:50 -0000 1.24 +++ detail/reversible_ptr_container.hpp 28 May 2007 13:35:10 -0000 @@ -35,7 +35,11 @@ #include <boost/utility/enable_if.hpp> #include <boost/type_traits/is_pointer.hpp> #include <boost/type_traits/is_integral.hpp> + +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION #include <boost/serialization/split_member.hpp> +#endif + #include <algorithm> #include <exception> #include <memory> @@ -46,12 +50,13 @@ namespace ptr_container_detail { - +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION template< class T > inline T const& serialize_as_const( T const& r ) { return r; } +#endif template< class CloneAllocator > struct clone_deleter @@ -545,6 +550,7 @@ return replace( idx, x.release() ); } +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION // // serialization // @@ -602,7 +608,7 @@ } BOOST_SERIALIZATION_SPLIT_MEMBER() - +#endif }; // 'reversible_ptr_container'
Sebastian Ramacher wrote:
As of version 1.34, Boost.PtrContainer supports serialization as defined by Boost.Serialization. Now I'd like to propose a switch to disable this feature. The attached patch adds checks if BOOST_PTR_CONTAINER_NO_SERIALZATION is defined around the serialization related code blocks and enables/disables serialization support.
It's not that I don't like serialization support but on a Debian system you have to install libboost-serialization-dev and libboost-serialization1.34.0 just to use Boost.PtrContainer.
The patch was created against CVS HEAD but I'd gladly provide a patch against 1.34 if it finds any interest.
In my view, a cleaner solution would be to move the serialization code to be external to the container and then optionally included. So, for example, #include <boost/ptr_container/ptr_list_serialize.hpp> would get you the serialization stuff. I didn't look exhaustively, but it looks the the serialization code uses only public interfaces on the containers so this approach should be easy and it avoids all the #ifdef hackery. It would also mean that the serialization dependency is 'off' by default and only gets included at the request of the user. I've been advocating that we move to this approach as much as possible within boost so that there's as much consistency as possible across boost libs w.r.t. this issue. Jeff
Jeff Garland said: (by the date of Mon, 28 May 2007 08:02:36 -0700)
So, for example,
#include <boost/ptr_container/ptr_list_serialize.hpp>
would get you the serialization stuff. <snip> only gets included at the request of the user.
Yep. Seems a good solution for me. -- Janek Kozicki |
Janek Kozicki wrote:
Jeff Garland said: (by the date of Mon, 28 May 2007 08:02:36 -0700)
So, for example,
#include <boost/ptr_container/ptr_list_serialize.hpp>
would get you the serialization stuff. <snip> only gets included at the request of the user.
Yep. Seems a good solution for me.
Seems good to me, too. I'm gonna work on that and post my efforts here. Sebastian
Sebastian Ramacher said: (by the date of Mon, 28 May 2007 16:47:49 +0200)
As of version 1.34, Boost.PtrContainer supports serialization as defined by Boost.Serialization. Now I'd like to propose a switch to disable this feature. The attached patch adds checks if BOOST_PTR_CONTAINER_NO_SERIALZATION is defined around the serialization related code blocks and enables/disables serialization support.
It's not that I don't like serialization support but on a Debian system you have to install libboost-serialization-dev and libboost-serialization1.34.0 just to use Boost.PtrContainer.
That's an interesting problem. What should be the policy about serialization support: 1. the serializaiton support is written in a boost library outside of boost::serialization (the case here), 2. or should it be written only inside the boost::serialization library (frequent case with other libraries). So that a non-serialization library will not pull serialization by header dependencies... ? -- Janek Kozicki |
Janek Kozicki wrote:
Sebastian Ramacher said: (by the date of Mon, 28 May 2007 16:47:49 +0200)
As of version 1.34, Boost.PtrContainer supports serialization as defined by Boost.Serialization. Now I'd like to propose a switch to disable this feature. The attached patch adds checks if BOOST_PTR_CONTAINER_NO_SERIALZATION is defined around the serialization related code blocks and enables/disables serialization support.
It's not that I don't like serialization support but on a Debian system you have to install libboost-serialization-dev and libboost-serialization1.34.0 just to use Boost.PtrContainer.
That's an interesting problem.
What should be the policy about serialization support:
1. the serializaiton support is written in a boost library outside of boost::serialization (the case here),
Yes -- because we want the serialization code located 'near' the details of the types being serialized. The authors of these libraries understand the underlying structures and how best to serialize them. If the structures change the serialization might change so then we would have to coordinate cross-library updates.
2. or should it be written only inside the boost::serialization library (frequent case with other libraries). So that a non-serialization library will not pull serialization by header dependencies...
?
Nope. See my other response. With non-intrusive serialization the dependency on serialization can be strictly optional and up to the user. This is the best of both worlds. Note that there may be some libs where this is harder to do (multi-index), but I believe this is the approach we should aspire towards. Jeff
Sebastian Ramacher skrev:
As of version 1.34, Boost.PtrContainer supports serialization as defined by Boost.Serialization. Now I'd like to propose a switch to disable this feature. The attached patch adds checks if BOOST_PTR_CONTAINER_NO_SERIALZATION is defined around the serialization related code blocks and enables/disables serialization support.
Thanks. I'll give a better answer tomorrow when I get some more time on my hands.
It's not that I don't like serialization support but on a Debian system you have to install libboost-serialization-dev and libboost-serialization1.34.0 just to use Boost.PtrContainer.
Oh. That's pretty annoying. But you don't have to build Boost.Serialization, do you? Let's see if we can fix this with 1.34.1 too. I'm not sure the macro approach is the right one yet. -Thorsten
Thorsten Ottosen wrote:
Let's see if we can fix this with 1.34.1 too. I'm not sure the macro approach is the right one yet.
Personally, I don't think this is important enough to fix in 1.34.1 -- it's not an emergency. Jeff
Thorsten Ottosen wrote:
Oh. That's pretty annoying. But you don't have to build Boost.Serialization, do you?
No, you just have to install the serialization packages.
Let's see if we can fix this with 1.34.1 too. I'm not sure the macro approach is the right one yet.
I'm currently implementing Jeff Garland's approach (mentioned at http://article.gmane.org/gmane.comp.lib.boost.devel/160068). I've got it working here. It just needs some more testing on other platforms before I'll post it here. Sebastian
Did anyone already look into it? http://lists.boost.org/Archives/boost/2007/05/122409.php http://svn.boost.org/trac/boost/ticket/1027 Sebastian
I've implemented Jeff's approach now. The attached archive includes a patch which removes the serialization related code from the class definitions and several files adding serialization support. The patch also adds an #include <boost/ptr_container/serialize.hpp> to PtrContainer's serialization test. boost/ptr_container/serialize_ptr_array.hpp: serialization support for ptr_array boost/ptr_container/serialize_ptr_deque.hpp: serialization support for ptr_deque boost/ptr_container/serialize_ptr_list.hpp: serialization support for ptr_list boost/ptr_container/serialize_ptr_map.hpp: serialization support for ptr_map and ptr_multimap boost/ptr_container/serialize_ptr_set.hpp: serialization support for ptr_set and ptr_multiset boost/ptr_container/serialize_ptr_vector.hpp: serialization support for ptr_vector boost/ptr_container/serialize.hpp: includes all the above listed headers Sebastian
participants (4)
-
Janek Kozicki -
Jeff Garland -
Sebastian Ramacher -
Thorsten Ottosen