Re: [boost] [xint] quick review

Subject: Re: [boost] [xint] quick review
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2011-03-15 09:48:17

"Steven Watanabe" <watanabesj_at_[hidden]> wrote in message 
news:4D7E2D5D.5050304_at_providere-consulting.com...
> I don't think fixed size integers are necessary
> for a Boost bigint proposal to begin with.

Why?
First, AFAIK a significant portion of 'bigint' usage falls into the realm of 
cryptography and encryption keys which usually have fixed power-of-two sizes 
and both 'fixed' and 'power-of-two' almost always translate to great 
simplification/efficiency improvements when one gets to the implementation 
level. This naturally translates to the question "why should I pay for usage 
of new, try, catch and throw if all I want is to construct a statically 
known fixed-size public RSA key and use it to verify a message"?
Second, AFAICT they are trivial to implement (with the right internal design 
of course, which was demanded of XInt long time ago but it never happened).

> However,
> since are provided, I'd like them to be handled
> as well as possible. Chad has already said that he
> expects support for them to improve and that's
> good enough for me, since it won't require breaking
> the interface.

Maybe I've missed it but I haven't seen concrete ideas as to how exactly 
Chad plans to do it (especially if he continues to stick with the current 
design and the attitude of not being bothered that dynamic memory allocation 
and exception handling are used where there is no really need for either).

>> Probably a fraction of the time spent arguing about it (and coming up 
>> with pointless arguments like that of a 'performant swap')...
>
> Pointless?

Defending dynamic-memory allocation (as opposed to static-sized/stack 
storage) solely with the argument that it allows for faster swaps is 
pointless: who designs a class to have a fast swap while paying for it in 
almost all other operations (i.e. pessimizes real usage for the sake of an 
auxiliary operation)? Plus, swaping fixed-size integers (PODs) is still 
pretty trivial (a few rep movs or memcpy calls).

>> The fact that you refuse to listen to advice, even such 'ancient truisms' 
>> as 'decoupling is always right',
>
> It isn't. If there's one thing I hate more than
> anything else, it's blindly applying rules,
> while forgetting the reason that the rules
> exist to begin with.

Juraj probably had a nice laugh seeing me accused of blindly following rules 
;-)

My statement may have been overly simple, but with all other things being 
equal (e.g. no efficiency compromises) decoupling can be seen as the 
opposite of writing spaghetti code, i.e. the opposite of something that is 
always wrong and in that sense right.
It also need not imply an expanded public interface.

-- 
"What Huxley teaches is that in the age of advanced technology, spiritual
devastation is more likely to come from an enemy with a smiling face than
from one whose countenance exudes suspicion and hate."
Neil Postman