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