Re: [boost] [serialization] use of unsigned int instead of size_type

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-02-11 13:53:12

I was expecting to see your enhancements for arrays to get
included and for collection_size (or whatever)  to be part of this.
I'm not sure what status of this is and/or if it conflicts with the recent 
feature
freeze.

I've been working only on things that don't affect features.
In particular.

a) fixing a bug in versioning of collection members
b) performance tweaks
c) keeping up with changes in other parts of boost
that show up as test failures in the serialization library.
d) trying to address failures that come with new compilers
and standard libraries (stlport 5.0?)

Things I would like to do if I had the time would be

a)  investigate and clarify some issues regarding DLLS
and serialization.
b) setup execution profiling for the library.
c) add a section to the manual discussing various approaches
to extending the library.

And finally in order to permit the serialization library to
be tested on the platforms that its currently supports, a
different test framework will have to be used.  This is not
urgent but it will require some effort.

On a related note - moving to bjam v2 has been mentioned.
Setting up the Jamfile for serialization caused me lots of
pain.  This permitted me to skip many tests that didn't make
sense for particular environments.  I can only speculate if
this is transferable to V2 and what kind of effort that might
require.

Robert Ramey

Matthias Troyer wrote:
> On Feb 10, 2006, at 8:39 AM, Robert Ramey wrote:
>
>> David Abrahams wrote:
>>> Matthias Troyer <troyer_at_[hidden]> writes:
>>>
>>>>> It's still not clear what this should be changed to - if in fact
>>>>> it should be changed at all.  std::size_t is a candidate - but I
>>>>> was under the impression that there might be interest in defining
>>>>> a special type for this - like collection_size_t or ?
>>>>
>>>> Indeed that's what's needed, and I have all the patches ready that
>>>> would need to be applied to do it.
>>>
>>> Please, guys, get this into 1.34.  It's embarassing and a little
>>> frustrating that this problem has persisted so long.
>>
>> It turns out that the internal library version number is going to be
>> bumped from 3 to 4 in the next release.  This has been necessary
>> to implement a correction to versioning of items of collections. So
>> its not a bad time to make such a change if that is indeed what
>> is necessary.
>>
>> My question is - what is the urgency.  The current system would
>> inhibit the serialization of collections of greater than 2 G objects.
>> But as far as I know no one has yet run into that problem.  So
>> I'm curious - has the usage of 32 bit count of objects created
>> some problem somewhere else?
>
> We have some vectors that are larger and which we cannot serialize
> using Boost.Serialization at the moment
>
> Matthias
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost