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 ? )