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. Robert Ramey Nikolay Mladenov wrote:
How should I understand this?
as "Nope, it should be fixed", or "Nope, deal with it"
or is it simply "get lost"?
This "simple" fact causes incompatibility problems between 64 and 32 bit archives.
Nikolay
On Tue, Mar 3, 2009 at 11:22 AM, Robert Ramey <ramey@rrsd.com> wrote:
Nope, it's just a fact.
Robert Ramey
Nikolay Mladenov wrote:
Hi,
I the basic_binary_iprimitive.ipp (and I suppose other files) the size of the strings is serialized as std::size_t and not as serialization::collection_size_type. Is that intentional?
Thanks,
Nikolay Mladenov _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost