Re: [boost] Crypto Proposal

Subject: Re: [boost] Crypto Proposal
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2010-04-14 11:23:06

"Chad Seibert" <chadseibert_at_[hidden]> wrote in message
news:BAY113-W22637C5D23F9712BD3FB39D3120_at_phx.gbl...
>> On 12/04/2010 7:52 AM, Domagoj Saric wrote:
>> IMNHO that's a failed test by any standard (worse than OpenSSL and
>> Crypto++)...
>> (must I really pay for e.g. virtual inheritance, dynamic_casts,
>> by-std::string-runtime-algorithm-lookups etc. etc... for such a simple use
>> case?)...
>
> That's because you built Botan in whole; it has the ability to build only
> parts of itself.

I built other libraries like that and they still fared (much) better. When you
avoid 'shooting your optimizer in the foot' with virtual functions/function
pointers/similar 'brick wall' indirections, a decent linker (supporting function
level linking or even link time code generation) can pretty much discard
most/all unused code from (statically) linked libraries.

The worst, bloat-wise, possible ofense one can make is to mix template classes
with virtual functions and dynamic_casts (this creates huge RTTI records as well
as exposes your class names in the final binary).

> If we don't like the inheritance structure, I can certainly remove it when
> porting.

'An' inheritance structure is not wrong in itself if it flows naturally from the
problem domain and 'good' design rules, but 'hardcoding' the use of virtual
inheritance and/or virtual functions (or even dynamic memory allocation and
exceptions), when those are not actually necessary for all usage models, _is_
'evil' (among other things, that's what makes std::streams the terrible failure
that they are)...
Any such design descisions that prevent even the best optimizers from removing
unused functionality apriori fail the 'you do not pay for what you do not use'
rule...

> Also, I certainly agree that the runtime lookup of algos is REALLY BAD and
> doesn't take advantage of the IH, as noted above. I agree it needs to be
> replaced.

Well it is actually not bad "in itself", to the contrary it is quite useful if
not necessary in the most general use cases (like detecting algorithms from
textual sources like HTML)...it becomes 'really bad' or 'downright evil' when it
is the 'only' way to do it or the way that the library internaly does it...

>> From this I gather that the original author plans to continue to develop and
>> maintain the original library, in which case I wonder what would be the
>> purpose
>> of having a library that is nothing more but a 'parallel' 'boostified'
>> version
>> of the original that in itself offers nothing new and is updated only after
>> the
>> original one is updated?
>
> I agree that this version should become *the* version, but I was completely
> absent-minded and didn't bring that up when discussing this with him. I'll ask
> him ASAP.

Great...but, since you seem to care about general efficiency issues (which makes
me very happy ;) I must ask again, why Botan? ...because, of the libraries I've
tested, it was the worst in this regard...

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