Considering your portability context (mine is even narrower): 1. the binary_archives already serialize boost::serialization::collection_size_type as unsigned int(uint32_t would still be better). 2.All this code will be unnecessary if the string serialization is not using "plain longs". On Wed, Mar 4, 2009 at 8:24 AM, troy d. straszheim <troy@resophonic.com> wrote:
Robert Ramey wrote:
Nope, It's not intentional.
I don't remember why it is the way it is. Collections evolved to become more efficient and in the process collection_size_type came into being. Since std::string was already primitive and had a special implemention there hasn't been any motivation to mess with it. I'm not even that enthusiastic about colllection_size_type. Turns out that each std collection has its own size_type. So this makes thing even more confusing.
It's the way it is because there was no obvious better choice.
I think it is a reasonable choice. The more control serialization gives me over how things are stored, the less likely it is that a change in the serialization library will make it impossible for me to maintain an archive that is binary compatible with previous versions of serialization. (In our case, the previous version is v1.33.1, and in this case one needs special handling for strings anyhow.) For other containers, the fact that serialization maps the varying size_types of std collections to one type simplifies things. If I don't like it, I can supply my own serialization routine for the container in question. In the general case (as has already been discussed ad nauseam), I'd argue that 'portable' has a context-dependent meaning (e.g. are ieee754 floats 'portable' for this use case? Is little/big endianness required?) and it is up to the user to build an archive that implements whatever 'portable' is to them.
Regarding the complaint about strings. For our (perhaps narrow) definition of portable:
* 32/64 bit intel platforms, linux and osx, which implies little-endian archives
* floats stored on disk in ieee754 format
* serializable types required to use stdint typedefs where types vary across the platforms we run on (for us this basically means 'no plain longs', but when/if 128 bit platforms come around, we may need to go back and change our 'ints' to int32_t)
* binary compatible with archives from a venerable custom binary archive built on top of 1.33.1.
We can get away with just the following in our portable_binary_iarchive_impl: template<class Archive, class Elem, class Tr> class portable_binary_iarchive_impl : public basic_binary_iprimitive<Archive, Elem, Tr>, public basic_binary_iarchive<Archive> {
// ...
void load_override(std::string& s, BOOST_PFTO int) { uint32_t l; this->load(l); s.resize(l); this->load_binary(&(s[0]), l); }
void load_override(class_name_type& t, BOOST_PFTO int) { std::string cn; cn.reserve(BOOST_SERIALIZATION_MAX_KEY_SIZE); this->load_override(cn, 0); if(cn.size() > (BOOST_SERIALIZATION_MAX_KEY_SIZE - 1)) throw_exception(archive_exception(invalid_class_name)); std::memcpy(t, cn.data(), cn.size()); // borland tweak t.t[cn.size()] = '\0'; }
void load_override(boost::serialization::collection_size_type& t, BOOST_PFTO int) { uint32_t l; this->load(l); t = l; }
-t _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost