Boost logo

Boost :

Subject: Re: [boost] [xint] quick review
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2011-03-25 06:36:36


"Steven Watanabe" <watanabesj_at_[hidden]> wrote in message
news:4D7F8B1B.8050502_at_providere-consulting.com...
> On 03/15/2011 06:48 AM, Domagoj Saric wrote:
>>
>> "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?
>
> A Boost library does not need to be all things to all people.
> It does need to have a clearly defined scope, and it
> does need to do it well. I would not generally vote
> against a library because it is missing feature X,
> even if X is something that I actually need.

Does it need to be "80%" to "80%" of the people?

It is not that "I need X", but that many people need/want X _and_ it is
relatively trivial to provide X and to, while providing X, implicitly make
the library better in other ways (easier extensibility and maintainability,
reduced template bloat and compile times...)...

But, most importantly, the core issue is the "to begin with"...If the
current design and interface (and the author's attitude) left room for
'proper fixed sized integers support' later, without breaking the interface
(not that I would object to breaking it but simply know that otherwise
change would never happen), then my objections would be vastly toned down
(maybe even to an acceptance vote)...However this is not the case here...

>> 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"?
>
> And of course these things are so much more
> expensive than the modular exponentiation
> required by RSA...

That's just an overly simplistic argument used just way to often to justify
premature pessimization and the production of bloatware. And it really
saddens me when I see it used by "prominent boosters"...
Of course these things are not "so much more expensive", unless of course
they cause a page fault (which sadly is not such a rare event even 'these
days' precisely because of the mass production of bloatware...no matter how
much RAM you install 'Bill' always finds a way to take it away)...
They do however slow down the 'modular exponentiation' itself (additional
indirection, worse locality of reference, fragmentation, etc.) but most
importantly they induce code bloat and as such affect the whole application
(and the entire system in fact). This reasoning is not the fallacious type
of the slippery slope argument because the compounded bloat effect is plain
obviously demonstrated every day by user computers with OSs that simply idle
at the desktop with near 1GB of RAM usage...

I see no objective foundation for even having to defend certain efficiency
concerns that are IMO really self-evident. For example, if I write an audio
application, and I need, as an auxiliary operation, to verify a message, is
it so unusual to expect the crypto library used not to add more code to my
binary than all of the many dozens of DSP algorithms that make the core and
purpose of the application in question? See here
http://boost.2283326.n4.nabble.com/Re-Crypto-Proposal-td2671858.html for my
analysis of exactly such a problem with real world numbers that demonstrate
where does injudicious/by default usage of new, virtual and throw (or their
higher level monster-friends, like std::streams) lead...

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk