BOOST_NO_INTRINSIC_INT64_T
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? Robert Ramey
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? In other words, should these two be named: BOOST_HAS_INTRINSIC_WCHAR_T BOOST_HAS_INTRINSIC_INT64_T --Beman
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 :-) As for other one, we already have: BOOST_NO_INT64_T - if there is no std::int64_t defined in boost/cstdint.hpp, and BOOST_NO_INTEGRAL_INT64_T - if std::int64_t can not be used in integral constant expressions. Both are defined in cstdint.hpp BTW, and I believe this adequately covers this area, unless I'm missing something? John.
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
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
Robert, What is it that you actually want to know? Normally folks will: * Deal with short, int, long etc and then: * Deal with long long if BOOST_HAS_LONG_LONG is defined. * Or else deal with __int64 if BOOST_HAS_MS_INT64 is defined. The alternative is to: Deal with each int16_t, int32_t etc and then Deal with int64_t if BOOST_NO_INT64_T is not defined. Mixing the two approaches is what causes the problems :-) So... do you serialize by type or by width? HTH, John.
here it what I use it for: I have a class which has a member function for each type. e.g. #if BOOST_HAS_LONG_LONG save(long long); #endif save(uint_64); // compiler error iif uint_64 is only a typedef for long long) so I think I want to be able to say #if BOOST_HAS_LONG_LONG save(long long); #endif #if BOOST_HAS_INT64 && BOOST_INSTRINSIC_INT64 save(uint_64); // OK #endif Robert Ramey John Maddock wrote:
Robert,
What is it that you actually want to know?
Normally folks will:
* Deal with short, int, long etc and then: * Deal with long long if BOOST_HAS_LONG_LONG is defined. * Or else deal with __int64 if BOOST_HAS_MS_INT64 is defined.
The alternative is to:
Deal with each int16_t, int32_t etc and then Deal with int64_t if BOOST_NO_INT64_T is not defined.
Mixing the two approaches is what causes the problems :-)
So... do you serialize by type or by width?
HTH, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
here it what I use it for:
I have a class which has a member function for each type. e.g.
#if BOOST_HAS_LONG_LONG save(long long); #endif save(uint_64); // compiler error iif uint_64 is only a typedef for long long)
so I think I want to be able to say
#if BOOST_HAS_LONG_LONG save(long long); #endif #if BOOST_HAS_INT64 && BOOST_INSTRINSIC_INT64 save(uint_64); // OK #endif
What's wrong with: save(int); save(long); #ifdef BOOST_HAS_LONG_LONG save(long long); #elif defined(BOOST_HAS_MS_INT64) save(__int64); #endif ?? I don't think there are any types used for int64_t other than long/long long/__int64? HTH, John.
participants (3)
-
Beman Dawes -
John Maddock -
Robert Ramey