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
>> 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
>> // 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
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
>> 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
>> them to preferably not use int_least_helper, or at least recognise
>> the new
> Yes, agreed. If the code were written today, they would certainly be
> in namespace detail or similar.
I think the test code for this header uses a specialization of
int_least_helper. Will that be excluded?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk