Re: [boost] Re: Why no long long support in integer::int_t?

From: Stephen Nutt (snutt_at_[hidden])
Date: 2002-09-28 15:16:43

Jeffrey,

Sorry for the delay responding, I've been away from the list all week.

I fully agree that a long long could be any size, but your theory that a
long may be larger than a long long throws me.  I'll have to check the spec.

I can change the code to use something other than int64_t, but what?  Should
we add both longlong_t and ulonglong_t that are typedef'd to long long if
supported, or else int64_t for MSVC?

Should we add support into int_t for additional future types?  There may be
compilers in the future that support in addition to char, short, int, long,
long long, an extra long type that is larger than all of the others.
Perhaps it makes more sense to come up with an alternative way to specialise
the helper class.  Say, either alternating signed with unsigned, or making
signed specialisations negative.

The code compiles and runs on MSVC but fails on other compilers.  If anyone
wishes to debug it on gcc or Metrowerks please let me know and I'll send
them the changes.

Thanks for the interest and your detailed responses,

Stephen

----- Original Message -----
From: "Jeffrey C. Jacobs" <darklord_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, September 24, 2002 5:30 PM
Subject: [boost] Re: Why no long long support in integer::int_t?

> (Hope I'm not out of line bringing this back up)
>
> Just some thoughts on the 64,000-millibit question.
>
> First off, I think we should keep in mind that "long long" is very likely
to
> be added to the standard, but almost certainly will be added in such a way
> that it is not necessairily 64 bits.  Specifically, I'd expect the rules
to
> be rewritten:
>
> 1 == sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <=
> sizeof(long long).
>
> Granted, most of the time this will be implemented as:
> 1, 2, 4, 4, 8 (with char being 8 bits)
>
> It is POSSIBLE an implementation could define:
> 1, 2, 4, 4, 4
>
> Or even!
> 1, 1, 1, 1, 1
>
> Not to mention the DEC alpha [and likely many future compilers] would
> typically use:
> 1, 4?, 8, 8, 16
>
> [As an asside, anyone remember the __int128 MS supported on their DEC
Alpha
> compiler...?]
>
> The int_t template works well with this "implementation" detail and IMHO
> should stick with the abstraction layed out by the standard.  If "long
long"
> (Boost type def BOOST_HAS_LONG_LONG) is supported then long long should
> (neigh MUST IMHO) be included in integer.hpp.
>
> Stephen already suggested how this might be done (assuming you insert it
> into the sequence) and I agree with this but would recommend using "long
> long" only and #if defined(BOOST_HAS_LONG_LONG).
>
> However, ironically I have veired away to the main point of this
discussion
> AFAICT: __int64.  __int64 is a whole other can of worms IMHO from what
> integer.hpp may be used for.  Or more to the point, it BETTER serves the
> same purpose as the int_t template.  Yes, you could use the typedef for
> int64_t (baring the problems inherent in protocol -- and again I vote: if
it
> ain't native, it ain't supported) but, well, let me give you an example of
> how I would use int_t<n>:
>
> template <typename T>
> inline const T add_with_carry(const T lhs, const T rhs, T &carry)
> {
>     // Note, since T should always be Unsigned Integral,
>     // sign_traits<T>::unsigned should technically be the parameter types
>     // See thread on sign_traits<> elsewhere for detail.
>     typedef uint_t<numeric_limits<T>::digits + 1>::fast big_t;
>
>     big_t r_(big_t(lhs) + _big_t(rhs) + big_t(carry));
>     return detail::split_big_t(r_, carry);
> }
> //...
> namespace detail
> {
>     template <typename T>
>     inline const T split_big_t(const uint_t<numeric_limits<T>::digits *
> 2>::fast r_, T &carry)
>     {
>         // Note, digits * 2 because of multiplication (explain later)
>         // May be repeat of function of other library
>         // Low "Word" is Result, High "Word" is Carry
>         carry = r_>>numeric_limits<T>::digits;
>         return r_ & integer_traits<T>::const_max;
>     }
> }
>
> (This code is part of a library I am working on; probably redundant but if
> it shapes up as I hope and someone does not beat me to it, I will propose
it
> here later.  Sadly, INTERNALLY the compiler is already computing lhs+rhs
and
> setting a carry bit (flag) on x86 that is inaccessible at the C++ level so
I
> have this nasty, round-about way of obtaining it.  But then *I* would
> suggest something like:
>
> #if defined(INTEL_MS_COMPILER)
>     __asm
>     //...
> #elif defined(COMPILER_xxx)
>     //...
> #else
>     // Above code
> #endif
>
> But if I wrote it that way I know I'd be flame-roasted big-time!)
>
> The point being, what I want from an int_t<> is a way to go from integral
> type T to some type big_t large enough to store "add with carry" (or
> multiply with carry) the same way my platform does.
>
> To me, the easiest way to do this is to have a separate MS-implimentation
of
> int_t and the int_least_helper that uses ALL the sized MS types:
>
> __int8
> __int16
> __int32
> __int64
> __int128 [on DEC Alpha]
>
> [then don't bother with numeric_limits?] since we know __int8 is 8 bits on
> all platforms supporting __int8 (MS)  -- that's why it's called __int8
after
> all.  :)  But actually HOW to support the MS extensions I want to ignore
for
> now and get back to my chief concern: is sizeof(long long) ==, < or >
> sizeof(__int64).
>
> Clearly it could be ANY of those relations, and although not any time in
the
> forseeable future, it is possible sizeof(int) > sizeof(__int64).  In fact,
> there is no "true" comparison between __int<n> and the intrinsic types any
> more than we can guarentee that sizeof(wchar_t) <= sizeof(short) [although
> IIRC sizeof(wchar_t) <= sizeof(long)].
>
> IMHO __int<n> of MS is a different class of relations from long, long
long,
> int, ... and should be handled separately.  At the same time, it should be
> handled s.t. the sample code need not care if it is using __int64 or long
> long or even long.
>
> Hope that's clear...?
>
> Jeffrey.
>
>
> "Neal D. Becker" <nbecker_at_[hidden]> wrote in message
> news:x88sn3iuhux.fsf_at_rpppc1.md.hns.com...
> > I wish boost::int_t would support long long.  Now it is restricted to
> > long.  Is there any good reason for this restriction?
> > _______________________________________________
> > Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>