FWIW - here is what I've been using up until now: // determine if its necessary to handle (u)int64_t specifically // i.e. that its not a synonym for (unsigned) long // if there is no 64 bit int or if its the same as a long // we shouldn't define separate functions for int64 data types. #if defined(BOOST_NO_INT64_T) #define BOOST_NO_INTRINSIC_INT64_T #else #if defined(ULLONG_MAX) #if(ULONG_MAX == 18446744073709551615ul) // 2**64 - 1 #define BOOST_NO_INTRINSIC_INT64_T #endif #elif defined(ULONG_MAX) #if(ULONG_MAX != 0xffffffff && ULONG_MAX == 18446744073709551615ul) // 2**64 - 1 #define BOOST_NO_INTRINSIC_INT64_T #endif #else #define BOOST_NO_INTRINSIC_INT64_T #endif #endif Robert Ramey Beman Dawes wrote:
On Tue, Mar 24, 2009 at 8:05 AM, John Maddock <john@johnmaddock.co.uk> wrote:
On Tue, Mar 24, 2009 at 1:38 AM, Robert Ramey <ramey@rrsd.com> wrote:
boost config includes BOOST_NO_INTRINSIC_WCHAR_T.
boost Is there any chance we might see BOOST_NO_INTRINSIC_INT64_T appear in the near future?
Should we reserve the BOOST_NO_* names for broken compilers that fail to correctly support a language or standard library feature?
Yes.
In other words, should these two be named:
BOOST_HAS_INTRINSIC_WCHAR_T BOOST_HAS_INTRINSIC_INT64_T
Well... last I looked an intrinsic wchar_t (ie not a typedef for an int type) *was* a std feature :-)
I guess "INTRINSIC" is confusing me. I assumed it meant the compiler was dealing with those types by inlining assembler code rather than calling functions, in the same sense as the word is used for intrinsic functions.
So I withdraw my objection.
Thanks,
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost