id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
653,[integer] add support for integers longer than long,me22,Daryle Walker,"{{{
With the endian discussion, I looked at Boost.Integer
to try to figure out why it didn't support long long
and __int64 where possible.  Since I couldn't see a
reason why it shouldn't, I went ahead and implemented it.

The only major interface change is adding additional
ValueUpper template parameters to int_(max|min)_value_t
and uint_value_t.  They default to 0, so no valid old
code should be affected.  They allow the programmer to
use, for example, uint_value_t<0x34567890,0x12> to
request a type that can hold 0x1234567890 or
int_min_value_t<-0x34567890,-0x12> to request a type
that can hold -0x1234567890, which will properly fail
if there are no types available over 32 bits (instead
of just truncating the constant and giving the wrong
result).

I also took the opportunity to add int_exact_t
templates for cases where an exact number of bits is
needed.  int_exact_t<32>::exact, for example.  (
Ideally this would be an additional typedef inside
int_t and uint_t, but I couldn't come up with a simple
way of doing that.  If it were acceptable to have exact
as a typedef for void when not available, it'd be easy,
but that goes against existing practice. ) If this
isn't wanted, it's very easy to remove.

If this looks good I'll try to decipher the macros in
the test suite to add some new ones.  The changes don't
cause any regressions from integer_test.cpp under my
g++ 3.3.6, 3.4.6, or 4.1.1.  In keeping with the
rationale and noticing that it works just about all the
compilers, I used no partial specialisation or
recursion, so I'm hoping that it'll work fine in the
more troublesome compilers as well.  Unfortunately
portage tell me that gcc-2* is to old to work with the
rest of my system, so I haven't been able to try.

}}}",Patches,closed,,integer,None,Problem,fixed,,