From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-03-22 16:33:54
Rob Stewart wrote:
> Without digging out the previous messages and confirming the
> matter, I think Jonathan's suggestion, quoted above, was simply
> that *when* the user wants separate translation units *and* the
> features that would typically require tight coupling, you could
> introduce a weaker link -- some form of indirection -- that would
> slow the resulting FSM or even complicate its specification, but
> would at least permit the functionality.
I think that's close to what I understood...
> This is right on target. *Since* the current design, with all of
> its requirements is so much slower, then the onus is on Andreas
> to explain why the requirements his library meets exceed those
> met by other FSM libraries and directly lead to the performance
> overhead. Clear distinctions regarding the performance
> improvements gained by avoiding the performance draining features
> in an FSM while still using this library will help to demonstrate
> that situation, too.
>> 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. In your case, what were
>> those alternate designs?
> Note that Jonathan is asking that those alternatives be
> documented. That way, other developers who wonder why you didn't
> try X will see that you did and they'll see why you decided it
> was not appropriate.
I have agreed to add such documentation in one of my previous answers.
>> 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.
>> This type of overview would probably be a useful component of any
>> library's documentation; in your case it is made absolutely
>> essential by the performance figures you cite.
> I don't think I can add any more to that. I think it is
> reasonable and clear.
It is but I'm not sure how this is relevant (I already agreed to add
-- 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk