|
Boost : |
From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-11-14 17:28:01
On Mon, 14 Nov 2005 22:24:41 00100 (CET), bwood <brass_at_[hidden]> wrote:
>
> Either way, with or without the embedded flush code, Boost
> serialization is less efficient than Ebenezer's Send in both
> tests.
What are we comparing here? You really need to give the Boost commuinity
more visibility into your code if you expect your arguments to be taken
seriously. There is nothing on http://www.webebenezer.net that resembles
documentation or a complete test application that can be compiled.
Today I timed how long it takes to build the two testcases
> mentioned in the original post on Nov. 8th. I used the date
> command so the numbers are only in seconds.
>
> list<int> list<int> and deque<int>
> -----------------------------------------------------------
> Boost 42 61
> -----------------------------------------------------------
> Ebenezer 12 20
Compile time is generally not the reason folks choose one library over
another. These decisions are generally based on features.
>Well since I use versioning heavily with boost.serialization this is
> >a must have feature for me.
>
> What happens if you want to change the type of an existing data
> member between releases - say from char to short?
>
You'd probably need to implement split save and load methods. The load
method would check the version number and (if old) read a char and put that
value into the member which is now a short.
// new code
struct myclass {
short m_data;
...
template<class Archive> void load (Archive& ar, const unsigned int version)
{
if (version > 1) {
char c;
ar & c;
m_data = static_cast<short> (c);
} else {
ar & m_data;
}
}
};
This is pretty simple assuming you're just widening the type to hold a
larger range of data, but if your'e changing the sematics, you'll clearly
need more code to interpret the old-style value and store it in your
new-style member. None of this is rocket science though.
-- Caleb Epstein caleb dot epstein at gmail dot com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk