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

From: Stephen Nutt (snutt_at_[hidden])
Date: 2002-09-03 18:34:07

> 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?
I was going to use int64_t and uint64_t.  I believe these *should* be
correctly typedefed for all platforms that support long longs.  It will all
be compiled within an BOOST_NO_INT64_T conditional.

> 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.
Yikes, now this is an issue.  Integer.hpp uses both std::numeric_limits and
integer_traits both of which return min and max values.  Now integer_traits
uses BOOST_STATIC_CONSTANT which will not work for compilers that do not
support static inclass member initialisation, and for those that do, they'll
also need to support long long compile-time constants, which you say is not
all.  However std::numeric_limits implements min and max functions which
persumably would work.  If I could specialise std::numeric_limits<int64_t>
and std::numeric_limits<uint64_t> if they were not done so by the builtin
limits.h I think I can get this to work.  However where would I place the
specialisations?  boost/limits.hpp seems the obvious place to start but it
is currently so clean I'd hate to start filling it up with compiler config
stuff.  I could put it in Integer.hpp, but that just seems plain wrong as it
is now dislocate from the rest.  Any ideas?

> I think the test code for this header uses a specialization of
> int_least_helper.  Will that be excluded?
To me int_least_helper seems like an implementation detail.  I'd personally
don't see a reason why this should be exposed and I feel it could be
excluded.  However I'm the newbie and I also wonder if people out there are
currently are using it.  I could change it to be backwardly compatible, but
it won't be as clean as it is today, or else we can make it explicitly an
implementation detail that shouldn't be used.