Re: [boost] [xint] Third release is ready, requesting preliminary review

Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: DE (satan66613_at_[hidden])
Date: 2010-05-01 12:43:33

on 01.05.2010 at 2:10
 Chad Nelson wrote :
>> however so far i have a suggestion about fixed_integer
>> for me it is counter intuitive that a fixed_integer<N> allocates
>> memory on the heap rather than on the stack [...]

> That was a tough decision. I started out with it on the heap, but
> there's no way to use the more-efficient swap(), operator=, or copy/move
> constructors that way. The best choice came down to which set of
> operations happens more commonly: swapping and assignment or creating a
> new object. I have no way of objectively measuring that for other
> people's code, but for my own, swapping and assignment edge out object
> creation, slightly.

that argument is enough for me and anyway it's _your_ decision
i only make a suggestion

...

>> this way you don't need to rewrite everything and you get rid of
>> costly allocation
>> in case you say that data allocated on the heap makes implicit sharing
>> possible i'd say that copying of reasonable size fixed ints beats
>> allocations in the end

> Since the data for a fixed_integer will always be the same size, the
> implementation could re-use older allocations instead of deallocating
> them and allocating new ones. I can see a fairly easy way to do that,
> and give the user control over what's being held if he wants it. Would
> that address your concern?

pretty much

>> oh and one more suggestion
>> when you define a variable that is not meant to be modified declare it
>> const
>> it immediately provides information to a reader and also compiler
>> ensures your intention

> Did I miss one? Other than possibly the zerodata stuff, I can't think of
> any that should be const but aren't. Hm, maybe some POD types in the
> internals...?

i meant this: in the followng code (monty.cpp)

00033 digit_t inverse0(const integer& n) {
00034     // Using the Duss and Kalisk simplification
00035     doubledigit_t x = 2, y = 1;
00036     digit_t n0 = n._get_digit(0);
00037     for (size_t i = 2; i <= bits_per_digit; ++i, x <<= 1)
00038         if (x < ((n0 * y) & ((x << 1) - 1)))
00039             y += x;
00040     return digit_t(x - y);
00041 }

the variable 'n0' is not modified so it actually is const (and should
be declared such)
'x' is not modified in this piece as well
this is a minor issue and concerns style of coding so it is arguable by
definition
however scott meyers, andrei alexandrescu and herb sutter recommend to
make everything const unless it must be modifyed
so you might want to decide to follow this recommendation
...or not

-- 
Pavel
P.S.
if you notice a grammar mistake or weird phrasing in my message
please point it out