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

Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-05-01 13:56:04

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/01/2010 12:43 PM, DE wrote:

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

Then I'll put it on the to-do list for the next release. I'd probably
have done it for this one, if I'd thought of it.

>>> 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 }

Ah, I see. POD types in the internals. :-)

> 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

(It's modified -- look at the end of the "for" line.)

> 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

It sounds like a good practice. It would be useful to catch some typos
at compile-time, where you use one variable but meant to use a different
one (something I've done on occasion). And as you said, it does make
code more readable, so I'll try to adopt now that I know about it.

But since the compiled code will be identical either way, for POD types,
I don't think it warrants combing through the code to correct violations
of it. I'll change them when I find them during refactoring.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvcazMACgkQp9x9jeZ9/wRWOwCfdV0ADlK/39w1cpKK2oPG7gvJ
am0AnRo0SltrbLE/bDi8m9zDQWATZCw4
=S+Qt
-----END PGP SIGNATURE-----