Boost logo

Boost :

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-03-12 12:41:15

Jonathan Turkanis wrote:
> Instead of replying point by point, let me summarize your message and
> reply in general.
> 1. My one sentence summary of your rationale was unfair

I think so, yes. To me, the undertone of that summary and other
sentences suggested arrogance on my part. You wrote:

"The requirements are X; I tried hard to satisfy X without compromising
performance, but I couldn't; therefore, it can't be done."

To me, especially the last 8 words imply that I think I have tried
*every* technique imagineable. This implies that I know pretty much
everything there is to know about C++ and associated techniques. I'm
very far from claiming that.

> 2. If I object to part of your library I should offer a concrete
> proposal to fix it

Either that or prototypes of techniques of which I said I can't see how
they will work. I said that because I have invested considerable time in
discussing things that might come to mind when one wants to improve
performance. I can't think of much else I can say in support of the
current design performance-wise. So I thought it would be more
productive if you or anyone else could make concrete proposals. Such a
proposal would either send me back to the drawing board or I would need
to argue convincingly why it doesn't work.

> 3. If I want to understand where the performance bottlenecks are, I
> should examine the code.

No, I didn't mean that in the generality your summary suggests. In *one*
*specific* case I thought it is better if *you* (Jonathan) look at the
code before I explain all the details in text. I did that because I
*assumed* (maybe wrongly) that you want a very detailed description for
which I really don't have the time at the moment.

> I'm still not sure what part of my summary was wrong,

See above.

> but I'm sorry I
> offended you.

Apology accepted.

> What I would like to see in the rationale is a
> comparison of a small handful (2-5) of alternate implementation
> technique, either approaches taken by other libraries or approaches
> you tried yourself early in development, together with an explanation
> of why they fail to satisfy the requirements.

That's interesting. I was under the impression that exactly such a list
of alternate implementation techniques would not satisfy you, because it
would in no way show that the design I chose is the best
performance-wise. And performance was your biggest concern, wasn't it?

> I realize you do
> mention some other frameworks, but you don't sketch their
> design/implementation or show how they fail to satisfy the
> requirements. Furthermore, readers wishing to understand the
> performance limitations of your library should not have to be told to
> examine the code.

That was never my intention, see above.

> You should provide a section giving a fairly
> detailed presentation of the implementation, explaining where the
> performance problems arise.

Ok, noted.


Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header. 

Boost list run by bdawes at, gregod at, cpdaniel at, john at