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
?
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
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