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

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-11 17:31:01

"Peter Dimov" <pdimov_at_[hidden]> writes:

> David Abrahams wrote:
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>
>>> David Abrahams wrote:
>>>> "Robert Ramey" <ramey_at_[hidden]> writes:
>>>>
>>>>> 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.
>>>>
>>>> IMO the size_type change should be considered a bugfix, as it was
>>>> not possible to portably serialize collections without it.
>>>
>>> The change is not trivial. Using a size_t typedef means that program
>>> A can write an unsigned int and program B can read an unsigned long.
>>> This will appear to work at first because the serialization library
>>> doesn't include archives where this is significant. Yet.
>>
>> I don't know exactly how to interpret your remarks.  It sounds like
>> you're describing the status quo here, which would seem to argue that
>> the change is necessary.
>
> The status quo is that the size of the container is consistently
> written or read as an unsigned int, is it not?

I think so, though I could be mistaken.

> Consider the simplistic example:
>
> void f( unsigned int ); // #1
> void f( unsigned long ); // #2
>
> void g( std::vector<int> & v )
> {
>     unsigned int n1 = v.size();
>     f( n1 ); // #1
>
>     size_t n2 = v.size();
>     f( n2 ); // ???
> }

Sure.  So how does this relate to serialization?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com