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