Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30

Subject: Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2017-10-04 14:25:15

On 04/10/2017 14:29, Bjorn Reese via Boost wrote:
> On 10/04/2017 01:30 AM, Ion Gaztañaga via Boost wrote:
> 
>> 2) Defaulting size_type to unsigned int is arbitrary and against 
>> existing practice. According to the usual STL rules, size_type shall 
>> come from the allocator, which knows what type can represent the 
>> number of elements that can be allocated. I find interesting the idea 
>> of expressing a different size_type to save space, but I am not sure 
>> if that should come from the allocator or from an option.
> 
> I cannot connect the dots between size_type and the allocator.
> 
> The Container requirements [1] only states that size_type should be an
> unsigned integer type large enough to contain any non-negative value of
> difference_type. And difference_type comes from the iterator.
> 
> The AllocatorAwareContainer requirements do not mention size_type.
> 
> [1] Section [container.requirements.general] in the C++ standard.

True. I revised with surprise the standard. It's only required for 
basic_string. This is a contradiction and IMHO a bug introduced in 
C++11. libc++ and msvc define it from allocator_traits (although 
libstdc++ defines it as size_t).

For C++03 it was

typedef to Allocator::size_type;

so it does not make sense to define it in another way, as it would break 
code. The original C++03 definition should have been updated to 
allocator_traits<T>::size_type.

Best,

Ion