Re: [boost] [xint] Fourth release, requesting preliminary review again

Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Marius Stoica (letto2_at_[hidden])
Date: 2010-06-03 09:40:38

On Thursday 03 June 2010 07:30:59 Chad Nelson wrote:
> I found a way, thanks to a suggestion from John Bytheway. :-)

That's really awsome :)

> 
> Since you'll probably use typedefs, it's not something you'll need to
> deal with often. Easy enough to change it, but I'm not sure I see the
> need yet.

> >> Would it? Though similar, they act very differently in the face of
> >> errors. The nothrow version also needs to support the Not-a-Number
> >> value, which requires a couple functions that don't make sense for the
> >> other types.
> > 
> > It's just a compile-time option like the other ones.
> 
> Not entirely, due to those two extra functions. And logically it's a
> distinct type.
> 

The more i think about it i think you should go for a policy based design.
Rigth now there is the obvious problem that you don't have a 
nothrow_fixed_integer.

Maby you can do something like this :

integer_t <
        throws<false>,
        size<128>, // 0 means unlimited
         thread_safe<false>> myint;

You could also have some other policies 
  -overflow policy( become nan, overflow to negative)
  -signed/unsigned policy

> That might save a few bytes of memory, but it would make the entire
> library slower, because it would have to check to see whether to use the
> data_t object or not before every operation. Memory isn't so precious
> that I'd consider that a good trade-off.
> --

Doesn't seem to bad to me, the advantages quite serious
-if you have a lot of small ints you save a lot of memory( i think an data_t 
would be more than 3x larger)
-for example you can put them in a vector without having pointers to 
everywhere(less fragmentation)
-you can allocate them on the stack without needing to dynamically allocate 
memory wich is quite expensive and nondeterministic

For that you will need to

-add a few instructions to every function(not very much)
-check a flag (not very costly xoring and comparing are the cheapest ops and it 
will have good branch prediction )
-add another pointer(probably the most serious issue, but you already have a 3 
pointer indirection -  maby you can make it so you can keep that ? )