Boost logo

Boost :

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


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_HAS_MS_INT64, and

What version of boost are you referring to ??

$ 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)

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:

   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

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.
> Where the following would hold: BOOST_HAS_INTRINSIC_INT_64_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

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

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



Boost list run by bdawes at, gregod at, cpdaniel at, john at