Jonathan Turkanis wrote:
Andreas Huber wrote:
Jonathan Turkanis wrote:
Andreas Huber wrote:
I think it is difficult to respond to statements like:
<quote> Possibly the joints between parts of machines defined in separate TUs must be weaker (i.e., less known at compile time) than the connections between collections of states implemented in a single TU. </quote>
Why should it be easy to respond?
I'm not saying responding should be easy. My point was that such statements are not likely to bring up useful answers.
Since you apparently don't know what I was suggesting, and you didn't bother to ask, I don't see how you can say this.
I believe I know very well what you were suggesting and I think - please correct me if I'm wrong - that should be apparent from my answer to the quote above: <answer> Yes, that occurred to me also. I don't see how I can make the link weaker without sacrificing static checking (or other requirements). And please: I'm NOT dismissing that possibility and concrete suggestions are always *very* welcome. </answer> I assume that you would have followed up on that had my answer shown any signs of misunderstanding. You didn't.
What I found shocking in your documentation was the statement that hand-written machines can be much faster than framework-generated machines.
One could probably produce an equally shocking case for just about any non-trivial library out there. My "mistake" was to measure it and publish the numbers.
This is ridiculous. Consider, for example, the iterators library, or Andrei and Dave's smart pointer library. If incrementing an iterator constructed using the framework could take up to twenty times as long as incrementing a hand-written iterator, or if copying a framework-generated smart pointer was twenty times as expensive as copying a hand-written smart pointer, these libraries would be dead in the water.
A much more adequate comparison would be measuring dumb C++ pointers vs. reference-counted smart pointers. IIRC, the overhead for copying was way beyond a few percentage points for shared_ptr. [snip]
As a reviewer, I could have done my job simply by pointing to the absence of justification, and left it at that.
Fortunately, there are many other things that matter in a review.
My objection to your library was based on a deficiency in the rationale. I don't know if this deficiency could be remedied without exposing fundamental problems in your library. The only way to find out would be to try to fix it.
Fix the documentation or the library? [snip]
Hah! You should read a few trial transcripts. But we digress.
Indeed.
All my other vague suggestions were attempts to suggest either (i) how the library could have been redesigned to yield better performance or (ii) how you might have documented the impossibility of achieving better performance given your requirements.
This is exactly something that I don't think I will ever be able to prove. I can only provide evidence that hints in this direction. New C++ techniques and idioms are discovered almost on a monthly basis and there's always the possibility that such a technique enables a much better implementation (e.g. I wouldn't have imagined that it is possible to enumerate overloads like Alexander does or I couldn't possibly have conceived the technique that makes possible the FOREACH macro). I think it is close to impossible for an individual to be proficient in all the currently known techniques, not to mention the ones that have yet to be discovered.
Okay, I shouldn't have said "impossibility"; maybe "impossibility, using known methods"
Even that is close to impossible.
or "unliklihood, using known methods"
I would agree if you replaced the last three words with: "using methods known to me and to people who studied the implementation". But I guess that's what you meant anyway.
But seriously, you must know that I'm not insisting you prove that you're library could not possibly be improved by yet-to-be-discovered-techniques.
Given your previous comments I couldn't be sure. To me those comments always had the air that something close to a proof is feasible. I must have misunderstood you.
I'm aware they were not fully fleshed-out proposals. I was hoping you would try to meet me half-way, by trying to figure out what I was getting at and explaing why it wouldn't work.
... which I did in the cases where I could imagine candidate solutions. I the cases where I couldn't see one I said so. Since the latter usually didn't lead to a follow-up on your part I assumed that you don't have a solution either. There's no meeting half-way in such a situation.
This is getting very vague.
I don't think so, but let's leave it at that then.
Things that I *consciously* avoided or unsuccessfully tried are described in the rationale.
If all the things you unsuccessfully tried are described in the rationale, then you didn't try very much. I was giving you the beneift of the doubt by assuming you had omitted describing your alternate designs.
What else should I have tried?
Normally, in designing a framework one considers a small handful (say two to six) of alternate designs which view the subject matter from completely different perspectives.
I agree with this general statement but I'm still wondering how you came to the conclusion that I haven't tried very much.
In your case, what were those alternate designs?
The documentation contains fairly visible hints that I considered: 1. GOF Visitor 2. Two-dimensional table of function pointers 3. Acyclic visitor Moreover, I also considered: 4. GOF FSM-like implementation (where subclassing is used for substates) 5. Herb Sutters function pointer FSM 6. Alekseys FSM 7. Dave's FSM variants I didn't bother to implement any of these with the exception of 3, because it became very apparent very soon that the other approaches would not satisfy my requirements and that it would be very difficult or impossible to modify them to suit. So, I really tried only one other approach. If you are still of the opinion this is not much I'd be interested in your *concrete* suggestions what else I should have tried.
Moreover, during any programmer career a bag of knowledge is acquired that is unconsciously applied to every programming job. Naturally, this bag of knowledge is not the same for everyone
This is obviously true.
which is probably the main reason why the rationale seems to be sufficient for some people while others find it unsatisfying.
This is just funny. People who find your rationale satisfying could be people who don't care about performance as long as it's good enough for their application or people who failed to consider the same design alternatives you failed to consider.
Which alternatives did I fail to consider?
Note the subjunctive mood.
Ah yes, now that you mention it.
Let me make one last attempt to explain what should be in the rationale. Look at section 16.2 of "The C++ Programming Language", 3d ed. Here Stroustrup gives two design criteria for a containers library, and then discusses three designs:
"Specialized containers and iterators" - satisfies the first criterion "Based Containers" - satisfies the second criterion "STL" - satifies both criteria
I'm not suggesting that you give such a detailed treatement as Stroustrup. However, if you were to give a similar overview of the landscape of possible FSM frameworks, and thoughtfully discuss the tradeoffs in flexibility and performace which each involves, reviewers might have some confidence that you are aware of the techniques which might be used to construct a fast, flexible FSM framework, and have carefully considered the design.
I'm not sure how this is relevant (I already agreed to add such documentation). -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.