From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2004-10-14 15:14:11
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 ??
$ 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 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk