Boost logo

Boost Users :

From: me22 (me22.ca_at_[hidden])
Date: 2007-06-05 08:58:05


On 03/06/07, Niels Dekker - mail address until 2007-11-30 wrote:
> Shams wrote:
> > 1. With most (all?) 64-bit Linux/Unix following the LP64 model:
> > http://www.unix.org/version2/whatsnew/lp64_wp.html
> >
> > int_t<64>::least could give either a "long" or "long long" .
> > uint_t<64>::least could give either a "unsigned long" or
> > "unsigned long long".
> >
> > In this case I'd prefer just "long" or "unsigned long".
>
> No problem, I guess. I guess that after adding long-long-support,
> int_t<64>::least would still select "long", rather than "long long", on
> a platform that has 64-bits "long" integers.
>
The current implementation method will give the potentially smaller of
the 2 types, so int_t<64>::least would give long if longs and long
longs are both 64-bits, just as it currently gives int for
int_t<32>::least when long and int are both 32-bits.

The implementation is quite ingenious, actually. On a proverbial
toaster with 42-bit everything, a request for int_t<39>::least would
give a signed char, the "smallest" type.

> > 2. However with M$ 64bit Windows following the ILP64 there is no other
> > choice but int_t<64>::least gives "long" or "long long".
>
> Hmmm... I wasn't even aware of ILP64! Thanks! Does Boost support ILP64
> platforms? If so, I guess int_t<32>::least should select _int32,
> instead of int, on such a platform!
>
The current implementation deals only in standard C++98 types.

Unfortunately, __int32 wouldn't fit in perfectly. int could plausibly
be 16 or 64 bits, so there's no way of knowing where in the ordering
to put it. Of course, some (rather reasonable) assumptions could be
make about platforms that do provide it.

> > 3. Now I remember someone already already come up with a patch?
>
> Apparently yes! Just after posting my question, I found a ticket,
> submitted by "me22" a year ago, and assigned to Daryle Walker:
> Ticket #653, "[integer] add support for integers longer than long"
> http://svn.boost.org/trac/boost/ticket/653
>
Apparently not everything got transitioned over to trac perfectly. On
SF it told you what this mysterious "me22"'s name was.

You can still find the patch in the mailing list archives:
http://lists.boost.org/Archives/boost/2006/06/106262.php

Or, if you're a boost admin, at
http://sourceforge.net/tracker/index.php?func=detail&aid=1507034&group_id=7586&atid=307586

There was someone else who also offered a similar patch a few months back.

> When would it be implemented within a Boost release version?
>
Hopefully soon :)

My patch is nearing a year old, but with 1.34 out the door and the
current push for more frequent releases, soon is plausible.

~ Scott McMurray


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net