Am Thursday 19 November 2009 14:15:46 schrieb Sebastian Karlsson:
Turns out I needed to handle serialization of strings explicitly, which fixed the error.
Looking at how class_name_type is handled throughout the source it seems its type is set in stone, furthermore it seems I pay at least an additional 128 bytes per exported class type, I guess this is convenient when serializing in text format for easy viewing, but for use cases where memory is at a premium and a hash would suffice it would be nice if this type was configurable throughout the system. I'm guessing this string is used in the extended_type_info system mentioned in the manual, leading me to believe that the lookup table for exported types uses a costly string compare to find the correct derived type.
Neither performance, memory use or archive size is mentioned as a specific consideration in the manual amongst the 11 goals, leading me to believe perhaps the library simply isn't suited for domains where these are of importance? This I would find rather sad, especially since this is areas where the language is often used.
there has been a discussion about that in the past. the type registration and object tracking functionality of boost.serialization is currently not configurable or replaceable by the user. the thread in which it took place was "Using boost::serializationinreal-timewithoutallocating memory" on boost-users in november 09. I think robert would welcome patches to change that.