[boost] Re: Proposal for cleanup of INT64 macros

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2004-10-14 15:14:11

Hi,

Markus Schöpflin wrote:
> 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.

What version of boost are you referring to ??

<snip>
$ find /cvs/boost/boost/config -type f |xargs grep INTRINSIC |grep 64
$ # whoops - no 'INTRINSIC' and '64' at the same line in any config file
$ # current state of the Boost main-CVS (head revision)
<snap>

Wishful thinking ? Well, I would like it, too ;+).

According to the docs there is no Boost.Config macro telling me if 
'int64_t' in fact is an alias to 'long long' or not.

Is one of the above possibilities always and for every compiler guaranteed ?

The documentation does not say too much about MS_INT64_T, either.
Is it about the name '__int64' instead of 'int64_t' ?

Does a Boost.Config user really have to check all these different 
spellings of 64 bit types like for example:

#ifdef BOOST_HAS_LONG_LONG
   support long_long_type
   support ulong_long_type
#elif defined(BOOST_HAS_INT64_T)
   support int64_t
   support uint64_t
#elif defined(BOOST_HAS_MS_INT64_T)
   support __int64
   support unsigned __int64
#endif

The example assumes there is only one signed/unsigned pair of intrinsic 
64 bit integers - as I mentioned before I have no idea if this is always 
the case.

Consider the "support for type" in this example is in fact something 
like template specialization or overloading a function, where it would 
trigger an ambiguity situation using separate #if(n)defS ...

However, is there a possibility to reduce the painful work a user has to 
go through to support 64 bit types properly, somehow (probably by using 
a typedef alias like done for long_long_type, already) ?

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

Well, I would not be too sure that the fact that there is an intrinsic 
int64 implies its vaildity within integral contant expressions.

> (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.

IMHO this is correct.

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

Really ? According to the documentation the INTEGRAL macro is about ICEs.

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

Regards,

Tobias