[serialization] boost::tuple
Serialization of tuple. This will come in handy when revamping serialization tests... http://svn.resophonic.com/pub/boost/boost/serialization/tuple.hpp http://svn.resophonic.com/pub/boost/libs/serialization/test/test_tuple.cpp -t
troy d. straszheim wrote:
Serialization of tuple. This will come in handy when revamping serialization tests...
http://svn.resophonic.com/pub/boost/boost/serialization/tuple.hpp http://svn.resophonic.com/pub/boost/libs/serialization/test/test_tuple.cpp
Very nice. I wrote a quick tuple-serialization header some time ago, but it was based on template specializations, using Boost.Preprocessor. This looks more clean. -- /Brian Riis
I like the look of this - though I'm not really familiar enough with boost::tuple to have a strong opinion. I also liked the test. Has this been tested with msvc 6.5? This platform gave me a lot of headaches with serialization of boost::variant but I went through to maintain the idea that serialization is supported on that platform. Better yet, which platforms has this been tested on? Does the author of Boost.Tupple have anything to say about this? Some attention should be paid to serialization traits. Should this be tracked, untracked, or the default. Also should it be versioned. it is now by default which is probably a good choice. Its not that I have any specific ideas regarding this, its just that I think that the defaults should be considered explictly as to their appropriate ness. Robert Ramey troy d. straszheim wrote:
Serialization of tuple. This will come in handy when revamping serialization tests...
http://svn.resophonic.com/pub/boost/boost/serialization/tuple.hpp http://svn.resophonic.com/pub/boost/libs/serialization/test/test_tuple.cpp
-t _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
troy d. straszheim wrote:
Serialization of tuple. This will come in handy when revamping serialization tests...
http://svn.resophonic.com/pub/boost/boost/serialization/tuple.hpp http://svn.resophonic.com/pub/boost/libs/serialization/test/ test_tuple.cpp
Be careful with non-portable code like the following: char fieldstring[3] = "T?"; fieldstring[1] = field_num + 48; // 48 is "0", and we are limited to 0-9 This will only work in ASCII-encodings, and not e.g. on IBM machines using EBCDIC encodings. Matthias
On 9/19/05, Matthias Troyer <troyer@itp.phys.ethz.ch> wrote:
troy d. straszheim wrote:
Serialization of tuple. This will come in handy when revamping serialization tests...
http://svn.resophonic.com/pub/boost/boost/serialization/tuple.hpp http://svn.resophonic.com/pub/boost/libs/serialization/test/ test_tuple.cpp
Be careful with non-portable code like the following:
char fieldstring[3] = "T?"; fieldstring[1] = field_num + 48; // 48 is "0", and we are limited to 0-9
This will only work in ASCII-encodings, and not e.g. on IBM machines using EBCDIC encodings.
Doesn't anyone who writes code like this write it as: fieldstring[1] = field_num + '0'; for just this reason? -- Caleb Epstein caleb dot epstein at gmail dot com
On Sep 19, 2005, at 3:33 PM, Robert Ramey wrote:
I like the look of this - though I'm not really familiar enough with boost::tuple to have a strong opinion. I also liked the test. Has this been tested with msvc 6.5? This platform gave me a lot of headaches with serialization of boost::variant but I went through to maintain the idea that serialization is supported on that platform.
Better yet, which platforms has this been tested on?
Does the author of Boost.Tupple have anything to say about this?
The implementation relies on the cons-list implementation of tuples. It is part of the public interface of Boost.Tuple, but not part of the TR1 specification. So if one wants to define serialization so that it works with any TR1 compatible tuple implementation, one must build the metafunctions around the get<N> templates. The downside of this is, that more compiler resources will be used. Also, at some point we'll roll in "Fusion" that will largely replace the current code of Boost.Tuple. Then we'll have more powerful means to iterate over tuples, in the style of MPL. But for now, my suggestion would be to consider implement serialization using TR1 compatible facilities. Or be prepared to change the implementation when fusion is included into boost. Best, Jaakko
Some attention should be paid to serialization traits. Should this be tracked, untracked, or the default. Also should it be versioned. it is now by default which is probably a good choice. Its not that I have any specific ideas regarding this, its just that I think that the defaults should be considered explictly as to their appropriate ness.
Robert Ramey
troy d. straszheim wrote:
Serialization of tuple. This will come in handy when revamping serialization tests...
http://svn.resophonic.com/pub/boost/boost/serialization/tuple.hpp http://svn.resophonic.com/pub/boost/libs/serialization/test/ test_tuple.cpp
-t _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
'
On Sep 19, 2005, at 3:33 PM, Robert Ramey wrote:
I like the look of this - though I'm not really familiar enough with boost::tuple to have a strong opinion. I also liked the test. Has this been tested with msvc 6.5? This platform gave me a lot of headaches with serialization of boost::variant but I went through to maintain the idea that serialization is supported on that platform.
I've put up a new implementation at http://svn.resophonic.com/boost/serialization/tuple.hpp http://svn.resophonic.com/boost/libs/serialization/test/test_tuple.cpp per Jaako's comments. This has been tested on gcc4 only, Robert. I saw how much the variant code had to change on the way in. Sorry. I don't have ms platforms available, and don't plan to. I seem to recall, when sifting through the internals of serialization code, (e.g. when attempting to write archives) finding those MS workarounds really distracting. Just so there's a voice on the other side of to-support-or-not-to-support-old-broken-ms question. Anyhow this one is much simpler than variant.
jarvi wrote: The implementation relies on the cons-list implementation of tuples. It is part of the public interface of Boost.Tuple, but not part of the TR1 specification. So if one wants to define serialization so that it works with any TR1 compatible tuple implementation, one must build the metafunctions around the get<N> templates. The downside of this is, that more compiler resources will be used.
So the tuple at boost/tuple/tuple.hpp doesn't have tuple_size<>. One is forced to resort to using either the cons<> stuff, or lots of preprocessor stuff. I went with cons.
Also, at some point we'll roll in "Fusion" that will largely replace the current code of Boost.Tuple. Then we'll have more powerful means to iterate over tuples, in the style of MPL. But for now, my suggestion would be to consider implement serialization using TR1 compatible facilities. Or be prepared to change the implementation when fusion is included into boost.
Best, Jaakko
fusion::tuple, (which I discovered after reading your mail) however, does provide tuple_size<>, so putting together serialization for boost::fusion::tuple is straightforward, and that's what I did, have a look. One thing I did notice while testing, though, is that one cannot instantiate, for instance tuple<bool,bool,bool,bool,bool, bool,bool,bool,bool,bool> (ten bools), but nine are fine. Am I missing something here? At any rate, the next option is the implementation I just put up, which would only require change of a couple header files and a using declaration if fusion::tuple moves. -t
troy d. straszheim wrote:
jarvi wrote: The implementation relies on the cons-list implementation of tuples. It is part of the public interface of Boost.Tuple, but not part of the TR1 specification. So if one wants to define serialization so that it works with any TR1 compatible tuple implementation, one must build the metafunctions around the get<N> templates. The downside of this is, that more compiler resources will be used.
So the tuple at boost/tuple/tuple.hpp doesn't have tuple_size<>. One is forced to resort to using either the cons<> stuff, or lots of preprocessor stuff. I went with cons.
Am I missing something here? I know that boost::tuple lacks a _size<> but I've always found a simple work-around with: template <typename T> size_t tuple_size(T tuple) { return boost::tuples::length<T>::value ; } ... But I agree, that convenience is lacking. Cheers, -- Manfred MetOcean Engineers www.metoceanengineers.com
Manfred Doudar wrote:
troy d. straszheim wrote:
jarvi wrote: The implementation relies on the cons-list implementation of tuples. It is part of the public interface of Boost.Tuple, but not part of the TR1 specification. So if one wants to define serialization so that it works with any TR1 compatible tuple implementation, one must build the metafunctions around the get<N> templates. The downside of this is, that more compiler resources will be used.
So the tuple at boost/tuple/tuple.hpp doesn't have tuple_size<>. One is forced to resort to using either the cons<> stuff, or lots of preprocessor stuff. I went with cons.
Am I missing something here? I know that boost::tuple lacks a _size<> but I've always found a simple work-around with:
template <typename T> size_t tuple_size(T tuple) { return boost::tuples::length<T>::value ; }
... But I agree, that convenience is lacking.
Ah, thank you, I somehow missed that. So no, one isn't *forced* to depend on the cons<> interface, but somehow I ended up there on the first go. Maybe somebody wants to add this to boost::tuples, then that serialization routine should work with either. -t
participants (2)
-
Brian Ravnsgaard Riis -
Caleb Epstein -
jarvi -
Manfred Doudar -
Matthias Troyer -
Robert Ramey -
troy d. straszheim