Subject: Re: [boost] BOOST_NO_INTRINSIC_INT64_T
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-03-25 13:04:15
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(ULONG_MAX == 18446744073709551615ul) // 2**64 - 1
#if(ULONG_MAX != 0xffffffff && ULONG_MAX == 18446744073709551615ul)
// 2**64 - 1
Beman Dawes wrote:
> On Tue, Mar 24, 2009 at 8:05 AM, John Maddock
> <john_at_[hidden]> wrote:
>>> On Tue, Mar 24, 2009 at 1:38 AM, Robert Ramey <ramey_at_[hidden]>
>>>> 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:
>> 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
> So I withdraw my objection.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk