Re:[boost] Re: Proposal for cleanup of INT64 macros

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 ??
>> 
>> <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. :-)

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

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;
#endif

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

Robert Ramey