[boost] Proposal for cleanup of INT64 macros

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2004-10-14 05:46:25

Hello,

currently we have a number of macros in boost which deal with whether INT64 
support is available of not and in what form it is available.

To my knowledge these are (in no particular order):

- BOOST_NO_INTRINSIC_INT64_T,
- BOOST_NO_INTRINSIC_UINT64_T,
- BOOST_NO_INT64,
- BOOST_HAS_MS_INT64, and
- BOOST_NO_INTEGRAL_INT64_T.

I propose to change these as follows.

- BOOST_HAS_INT64_T
- BOOST_HAS_INTEGRAL_INT64_T
- BOOST_HAS_INTRINSIC_INT_64_T
- BOOST_HAS_MS_INT64_T

Where the following would hold: BOOST_HAS_INTRINSIC_INT_64_T => 
BOOST_HAS_INTEGRAL_INT64_T => BOOST_HAS_INT64_T.

(I don't know where BOOST_HAS_MS_INT64_T would fit in above but I'm sure 
some MS expert will know.)

The reasons for this proposal are:

1. I think the BOOST_NO_.. macros are misnamed. They don't describe a 
defect (INT64 support isn't mandated by the standard) but rather an 
extension. Therefore they should be named BOOST_HAS_...

2. Most uses of the above macros are #ifndef(BOOST_NO_INT64) or 
#ifndef(BOOST_NO_INTEGRAL_INT64_T) or the like. This double negation makes 
the use harder to understand than neccessary.

3. I think it is safe to assume that when an intrinsic INT64 type is 
available, the UINT64 type will be intrinsic, too.

4. If one currently wants to know wheter an integral INT64 type is 
available, the correct way to check is #if !(defined(BOOST_NO_INT64)) && 
!(defined(BOOST_NO_INTEGRAL_INT64_T)). This would be facilitated to #ifdef 
BOOST_HAS_INTEGRAL_INT64_T .

Is there any interest in this proposal? Any comments and thoughts are welcome.

Markus