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