Zitat von Bob Walters <bob.s.walters@gmail.com>:
If I have understood, the data is stored using Boost.Interprocess. Could you clarify why do you force the stored types to be Serializable?
I'm not relying on the durability of the boost interprocess region. Nor am I trying to serialize the shared memory from directly to disk. Stefan has challenged me to do that
I didn´t realize ;)
, and I'm considering a variation which would do that, but it isn't without it's own issues. For now, I went with the approach of using serialization for sending K,V types to logs or checkpoints as a way to avoid those issues. My current concern with direct storage is that (assuming K and V may not be concrete types) it seems like it will require a lot of memory use tracking which could add an unwanted expense to shared memory pointer traversal.
if you keep using serialization we should also think about unifying this aspect of our libraries. as we've discussed before I have some ADL functions that avoid boost.serialization if possible. they 1. use std::memcpy() if serialization::is_bitwise_serializable<> yields true 2. use user-supplied functions, described here: https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html/... 3. only if 1 and 2 fails, invokes Boost.Serialization. so for a trans_map<int,int> for example, there would be no overhead(besides memcpy) and no calls to Boost.Serialization (and no compile-time instantiations!)