[serialization] Custom archive and arrays
I am currently adding support of C++ arrays to a custom oarchive.
My archive inherits from boost::archive::detail::common_oarchive and
implements save_override(), which will pass any unknown type to
boost::archive::save(). This enables me to implement non-intrusive
serialization.
When I pass an array to boost::archive::save(), it detects that this is
an array and then calls detail::save_array_type. This is where my
problem starts, as the function is hardcoded to always store a prefixed
array count, which is illegal in the format that my custom archive uses.
Would it be possible to lift this restriction?
My current workaround is to add an overload for arrays to my custom
archive, i.e.
template
On 1/22/16 2:40 AM, Bjorn Reese wrote: I presume we're talking about C++ intrinsic array rather than std::array.
My current workaround is to add an overload for arrays to my custom archive, i.e.
template
void save_override(const T (&data)[N]);
What is the problem with using this or some similar overload? Robert Ramey
On 01/22/2016 05:54 PM, Robert Ramey wrote:
On 1/22/16 2:40 AM, Bjorn Reese wrote:
I presume we're talking about C++ intrinsic array rather than std::array.
Yes.
My current workaround is to add an overload for arrays to my custom archive, i.e.
template
void save_override(const T (&data)[N]); What is the problem with using this or some similar overload?
Well, since I have found a workaround there is no problem per se. My concern is more that Boost.Serialization imposes a serialization sequence that is invalid for certain encoding formats. This means that we have to by-pass Boost.Serialization for the serialization of arrays.
On 1/22/16 9:55 AM, Bjorn Reese wrote:
On 01/22/2016 05:54 PM, Robert Ramey wrote:
My concern is more that Boost.Serialization imposes a serialization sequence that is invalid for certain encoding formats. This means that we have to by-pass Boost.Serialization for the serialization of arrays.
Hmmm - try thinking of the serialization library in a slightly different way. Think of it as a framework for implementation of serialization for other types. Then consider the specific types included in the library as "examples" of how to use the library. Think of overloading as "customization points". So you ARE bypassing the usual/default/expected implementation of the library in order to use your own. The only thing I can say about this is that perhaps built-in arrays shouldn't have been in the "primitive-set" and implemented like other STL types. Perhaps. But I don't think it's a big deal. When I did it, I thought in terms of a hierarchy - C++ builtin types as part of the "built-in" implementation. STL types as "standard add-ons" to the library and everything else as the users's responsability. If I had to live my life over I might have factored it in a different way - oh well. Robert Ramey
On 22-01-16 20:50, Robert Ramey wrote:
On 1/22/16 9:55 AM, Bjorn Reese wrote:
On 01/22/2016 05:54 PM, Robert Ramey wrote:
My concern is more that Boost.Serialization imposes a serialization sequence that is invalid for certain encoding formats. This means that we have to by-pass Boost.Serialization for the serialization of arrays.
Hmmm - try thinking of the serialization library in a slightly different way. Think of it as a framework for implementation of serialization for other types. Then consider the specific types included in the library as "examples" of how to use the library. Think of overloading as "customization points".
In that vein, how do you like a "decorating" wrapper that allows you to
override default behaviour:
#include <iostream>
#include
On 1/22/16 3:43 PM, Seth wrote:
In that vein, how do you like a "decorating" wrapper that allows you to override default behaviour: <snip>
generally I like this sort of thing. The library itself comes with a few wrappers to be used for things like this - and xml serialization. I'm not sure it's a good choice in this particular instance though as it requires the user to explicitly tie the serialization to the archive. I would expect one to overload the serialize function in the archive for native C++ arrays. If one had nothing else to do he could create an "archive adaptor" which would look like: class archive_add_special_array<typename base_archive> which would add the overload to any archive. They you'd just instantiate a new archive for each base archive etc. Robert Ramey
participants (3)
-
Bjorn Reese -
Robert Ramey -
Seth