From: Robert Ramey (ramey_at_[hidden])
Date: 2004-10-15 14:51:09
>Tobias Schwinger wrote:
>> Markus Schvpflin 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) <snap>
>> Wishful thinking ? Well, I would like it, too ;+).
>It was used in "boost/archive/polymorphic_[io]archive.hpp" but was removed
>yesterday. Honestly. :-)
LOL - I removed it yesterday. The cited file needs to know if int64 is an
intrinsic type or a synonym for some other type - e.g. long on a 64 bit
machine or ?. If it is, it will generate a compile error when the cited
file is compiled. I would like to avoid this. For my purposes, if it were
defined as a synonym for long long it would be ok so the above macros don't
quite give me what I need in this instance. I'm still undecided what to do
I suppose the above proposal would work for me. I would use
#if ! defined(BOOST_NO_INT64) && ! defined(BOOST_NO_INTRINSIC_INT64_T)
virtual void load(int64_t & t) = 0;
>> 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
I prefer sticking to the BOOST_NO... syntax. Yes it implies double
negatives in some cases - but it means I don't have to remember which is
negative and which is positive logic. (Foolish) consistency is a virtue
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk