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-03 02:31:21

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

On 05/03/2010 01:28 AM, vicente.botet wrote:

>>> What is the meaning of flags
>>> static const flag_t flag_negative = 0x01;
>>> static const flag_t flag_readonly = 0x02;
>>> static const flag_t flag_fixedlength = 0x04;
>>
>> The first is used (in the 'flags' bitfield) to denote a negative number.
>> The second identifies data_t items that are meant to never be modified
>> (the zero items assigned when new integers are created without
>> specifying a value, for instance). The third is used on fixed_integer
>> types, to tell the base_integer allocation code to use some special
>> handling for them. [...]
> 
> I don't understand why any of these informations is not stored on
> data_t.

flag_negative isn't stored in data_t because if it were, I'd have to
make a deep copy of every number when I only want to make it negative
for a temporary calculation.

flag_fixedlength isn't stored in data_t because that would defeat the
purpose of it, which is to identify a fixed_integer to the allocation
functions when no data_t has been allocated for it yet.

flag_readonly isn't stored in data_t because I'd have to store yet
another variable there to handle it, which would be inefficient because
I had plenty of room in this really handy flag variable that I already
had to have in base_integer anyway.

> In addition no information must be stored on base integer that
> concerns fixed_integer. This is a bad design option, IMHO.

And IMNSHO it isn't. Please give me the courtesy that you would offer
any professional that you meet in the physical world, and assume that I
have a good reason for every choice I've made until proven otherwise.

I know I'm overreacting, and that I shouldn't answer e-mails like this
when I'm tired. I do appreciate that I asked you guys to do this, and
that you're only trying to make it better. But please also remember that
it's a hell of a lot easier to criticize something than to do it
yourself. 'Nuf said.
- -- 
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/

iEYEARECAAYFAkvebbQACgkQp9x9jeZ9/wRmRwCbB/Kf1uajxL7o9XYzXk/yrhXW
5p0An2rvSyj8o2W7P0gjASAptRLW2cnW
=QoaL
-----END PGP SIGNATURE-----