[boost] Re: Why no long long support in integer::int_t?

From: Daryle Walker (darylew_at_[hidden])
Date: 2002-09-02 17:58:04

On Sunday, September 1, 2002, at 08:52 PM, bdawes_at_[hidden] wrote:

> At 09:43 AM 8/31/2002, Stephen Nutt wrote:
>
>> Thank you, I'll go ahead and make those changes.  Quick question 
>> though.
>> The current specializations are
>>  //  specializatons: 1=long, 2=int, 3=short, 4=signed char,
>>  //     6=unsigned long, 7=unsigned int, 8=unsigned short, 9=unsigned 
>> long
>>  //  no specializations for 0 and 5: requests for a type > long are 
>> in error
>>
>> It would seem 'cleaner' to shift everything along to make the new ones
>>  //  specializatons: 1=int64_t, 2=long, 3=int, 4=short, 5=signed char,
>>  //     7= uint64_t, 8=unsigned long, 9=unsigned int, 10=unsigned 
>> short, 11=unsigned long
>>  //  no specializations for 0 and 6: requests for a type > int64_t 
>> are in error
>
> Yes, agreed.

Will that change still work of the extended-long type was "long long" 
instead of "int64_t"?  What about a compiler without an extended-long 
type?

Also, one of the concerns brought up the last time this suggestion was 
given was that a compiler may supply extended-long type(s), but not 
allow them to be used as compile-time constants in value-based template 
parameters.  The CRC library uses this library in this manner.

>> However I worry if this might break existing code.  Is the template
>> int_least_helper supposed to be used outside of integer.hpp, or is it
>> purely
>> an internal implementation for the templates?
>
> They are just internal implementation details.
>
>>  If it is supposed to be
>> internal I wonder if I should move it into a nested namespace for the
>> following reasons.
>> 1) Make the fact that int_least_helper should not be used outside of
>> integer.hpp explicit
>> 2) Cause compile errors for anyone currently using int_least_helper 
>> forcing
>> them to preferably not use int_least_helper, or at least recognise 
>> the new
>> values.
>
> Yes, agreed. If the code were written today, they would certainly be 
> placed
> in namespace detail or similar.

I think the test code for this header uses a specialization of 
int_least_helper.  Will that be excluded?

Daryle Walker