[boost] Re: Proposal for cleanup of INT64 macros

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2004-10-15 03:37:05

Tobias Schwinger wrote:

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

It was used in "boost/archive/polymorphic_[io]archive.hpp" but was removed 
yesterday. Honestly. :-)

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

True, the only reference I discovered was in the serialization library, it 
was defined there.

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

Which possibilities?

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

Don't know.

> 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

Well, I would hope that <boost/cstdint.hpp> takes care of this, always 
giving you a type called [u]int64_t. Only when the special properties of 
this type matter you would have to use the macros.

> 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'm not sure if I understand you correctly? You mean "typedef uint64_t 
unsigned long long" where it is not already available?

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

It's not guaranteed, that is true. But do you know of a compiler which has 
an intrinsic 64 bit type which can't be used in integral constant expressions?

As a side note, which compilers actually would have 
BOOST_HAS_INTRINSIC_INT_64_T defined? The only 64 bit platform I have used 
is Tru64/Alpha and there int64_t is just an alias for long long.

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

Of course, you are right. Change the above sentence to "... whether the 
INT64 type can be used in an integral constant expression, ...".

Markus