Re: [Boost-users] [integer] Request: long long (64 bits) support for int_t and uint_t

From: me22 (me22.ca_at_[hidden])
Date: 2007-06-05 20:18:09

On 05/06/07, Niels Dekker wrote:
> I agree about it being quite ingenious.  And I like the fact that it
> supports 42-bit-everything-systems.  But still, personally I'd rather
> have it support all kinds of 64-bits platforms...
>
> > The current implementation deals only in standard C++98 types.
>
> And should it stay that way?
>
My proposed patch doesn't, which suggests my answer.

> I like your int_exact_t<Bits>::exact, Scott!  It could really be of
> help, for my own Boost-based project.  Still I don't like the fact that
> it will fail to get me a 32-bits integer (_int32) on an ILP64 platform.
>
> Why not having int_exact_t entirely based on the exact-width integer
> types from <boost/cstdint.hpp>?
>
The current implementation works in an entirely standard manner, which
I consider an advantage.

cstdint.hpp, on the other hand, consists solely of by-hand listings of
using declarations and typedefs that require manual configuration work
for new platforms.   Note the #error defaults not correct; you must
hand modify boost/cstdint.hpp. This is important for people using
boost on toasters with 11-bit bytes :P

For obvious reasons, the implementation cannot just blindly add
specializations for int_t<sizeof(int)*CHAR_BIT> and
int_t<sizeof(long)*CHAR_BIT>.

> Actually I was thinking of a far more simple implementation, as
> follows.  (In practice, I find it quite convenient to have the signed
> and the unsigned type grouped within one struct.)
>
I'm not sure if that is actually simpler, as it requires template
specialization, which has historically been avoided where possible,
for compatibility.  I think the problem platforms are being dropped in
1.35, however, so this may no longer be a problem.

How does the signed and  unsigned types together help you?  My concern
was simply to add support without changing semantics, so I haven't
looked at interface one way or the other.

If we're going all-out on interface, allowing specializations and
stuff, there are a number of other possibilities.  One fun one that's
even backwards compatible is still allowing int_t<25>::least and
uint_t<25>::least, but also int_t<25,unsigned>::least (and
int_t<32,signed>::least).

The reason I didn't consolidate ::exact into int_t and uint_t
originally was that it makes it annoying (or maybe impossible) to
preserve the non-existence semantics for the ::exact typedef when such
a type is unavailable.  Making it give void is easy and does almost
all the same things, but then you don't get an error from typedef
int_t<31>::exact myint; at typedef definition, only when the typedef
is actually used.  (I suppose a debate could be held on whether that's
a positive or a negative.  I suppose the void does fit well with the
"it's only an error if you try to use it" idea that comes up a few
times in D&E, but that's a language-level idea that's rather counter
to the application-level idea that's rather opposed to failing early
and fast...)

> AFAIK, such a template would correctly support any 64-bits platform,
> including ILP64.  What do you think?
>
It would certainly support all the desktops and servers I know of.
The question is how well it deals with embedded stuff and toasters.

Of course, I have no idea where (whether?) anyone uses boost/integer.hpp...

~ Scott McMurray