Re: Generalised reflection
Message: 4 Date: Fri, 12 Nov 2004 07:34:27 -0500 From: "Neal D. Becker" <ndbecker2@verizon.net> Subject: [boost] Re: Generalised reflection To: boost@lists.boost.org Message-ID: <cn2akj$qij$1@sea.gmane.org> Content-Type: text/plain; charset=us-ascii
George van den Driessche wrote:
[...]
Yes. Now imagine that I've got some helper functions for use with Boost.Python's pickling suite. But I want to use them with a C++ serialisation library. I'm going to have to factor a bunch of code out of those helper functions so that I can invoke them without using boost::python::tuple, and then write wrappers to use the factored-out code with the Boost.Python pickling suite. Instead, I want to write just the C++ serialisation code, and have that automatically wrapped up for use with Boost.Python pickling. It's a similar separation of layers.
Incidentally, I wrote about sharing boost c++ serialization with boost.python pickling, and posted code demonstrating this. Nobody seemed very interested. I think it's this post: http://tinyurl.com/6dbhb that you're referring to. In which case, I missed it, but yes, you're on the same topic.
One of the things that I noticed about serialisation code is that there's generally a symmetry between the reading and writing routines. So rather than write "this is how I load an X, and this is how I save one" I'd want to write "these are the things in X that need to be saved" and let some templates figure out what the corresponding routines are. And then it was this desire to serialise things automatically by specifying properties that led me on to think about a common architecture for language binding and serialisation. Maybe in the end you'd get declarations like: /// Properties for serialisation boost::properties< my_t, "my_t", boost::serialisation > .def( "my_int", &my_t::my_int, &my_t::set_my_int ) // After serialisation format version 4, // my_float no longer needed to be serialised .def( "my_float", &my_t::my_float, &my_t::set_my_float, boost::serialisation::in_format_version_range<>( 0, 4 ) ) ; /// Properties for scripting boost::properties< my_t, "my_t", boost::langbinding > // Use serialisation properties to implement pickling. .def_pickle( default_pickle_suite< my_t >() ) .def( "my_int", &my_t::my_int, &my_t::set_my_int, boost::langbinding::return_internal_reference<>() ) // We don't want to bind my_float, for whatever reason. ;
George van den Driessche wrote:
Message: 4 Date: Fri, 12 Nov 2004 07:34:27 -0500 From: "Neal D. Becker" <ndbecker2@verizon.net> Subject: [boost] Re: Generalised reflection To: boost@lists.boost.org Message-ID: <cn2akj$qij$1@sea.gmane.org> Content-Type: text/plain; charset=us-ascii
George van den Driessche wrote:
[...]
Yes. Now imagine that I've got some helper functions for use with Boost.Python's pickling suite. But I want to use them with a C++ serialisation library. I'm going to have to factor a bunch of code out of those helper functions so that I can invoke them without using boost::python::tuple, and then write wrappers to use the factored-out code with the Boost.Python pickling suite. Instead, I want to write just the C++ serialisation code, and have that automatically wrapped up for use with Boost.Python pickling. It's a similar separation of layers.
Incidentally, I wrote about sharing boost c++ serialization with boost.python pickling, and posted code demonstrating this. Nobody seemed very interested. I think it's this post: http://tinyurl.com/6dbhb that you're referring to. In which case, I missed it, but yes, you're on the same topic.
That is an earlier and uglier version. I played with a few approaches. The one I settled on is very simple and easy. It does suffer from being serialized twice - once by boost::serialize and again by python pickle, but in my case that's a good tradeoff for simplicity. Here is the current code I'm using: (I'm just extracting the part that relates to serialization): struct mt_pickle_suite : python::pickle_suite { static python::object getstate (rng_t& rng) { std::ostringstream os; boost::archive::binary_oarchive oa(os); oa << rng; return python::str (os.str()); } static void setstate(rng_t& rng, python::object entries) { python::str s = python::extract<python::str> (entries)(); std::string st = python::extract<std::string> (s)(); std::istringstream is (st); boost::archive::binary_iarchive ia (is); ia >> rng; } }; [...] class_<rng_t> ("rng", "Mersenne Twister", python::init<rng_t::result_type>( (python::arg ("seed")=4357), "__init__(seed=4357)\n" "Construct with optional seed\n" "@param seed: initial seed\n" )) .def_pickle(mt_pickle_suite()) .def ("getstate", &mt_pickle_suite::getstate) .def ("setstate", &mt_pickle_suite::setstate)
participants (2)
-
George van den Driessche -
Neal D. Becker