On Wednesday, December 18, 2002, at 9:16 AM, Neal D. Becker wrote:
Nothing is happening right now. I'm sorry if I didn't make this clear before: I'm _not_ doing this for you; you have to make the updated header and documentation yourself and show it to us for review. And please remember the concerns I brought up on earlier threads.What is the status of adding 64bit support to integer.hpp? I am looking for boost::int_t<n>::least for n > 32.
1. If 64-bits is already supported by the official C++ integral types, then nothing has to be done.
2. Unfortunately, most compilers (AFAIK) keep int == long == 32 bits instead of bumping long up to 64 bits. Those compilers could make a new type for 64 bit integrals. But remember:
The existence of these extra types is NOT guaranteed.
Your extension has to fall back safely for a compiler without extended integral types. It won't be accepted otherwise. (If it was accepted, then a conforming compiler that doesn't have extensions wouldn't work.) Maybe the preprocessor could be used here.
3. The implementations of the types in integer.hpp specialize templates for certain numbers. There are gaps in those numbers; those gaps are intentional, to reject too-large bit lengths. Don't fill in those gaps; you have to move them around or completely change the implementation.
4. The CRC library uses the resulting type from integer.hpp as a value-based template parameter. There is no guarantee that extended integral types can be used as value-based template parameters (since they're unofficial). Your extension will _break_ CRC. Since I'm also the CRC author, I'm willing to change CRC to be hard-coded to unsigned long. There may be other Boost libraries that make the same assumption. If there are, please let the maintainers of those libraries know so they can be part of the discussion.
Daryle
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
