Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-03-12 16:36:44


On Sat, 12 Mar 2005 15:57:10 -0500, David Abrahams wrote
>
> Haven't a few people been reporting that they won't even begin to
> apply this one because of particular limitations? Anyone who needs
> higher performance won't even get started.

Sure, and on the other hand we've had at least one testimonial that this was
the best fsm library they found -- served them well in a project. I've heard
the same sort of argument from people comparing std::string to a char*.
std::string: "it's too slow for my app". Fine for them, well at least until
they leak memory in their app, (of course, they won't use shared_ptr either --
too much memory). That doesn't make std::string less useful for me or
thousands of other programmers. I'm interested in using fsm in distributed
server apps where the library overhead is completely irrelevant to application
performance. The documentation was certainly upfront about the performance
implications -- so it doesn't try to misrepresent itself -- if it did I would
have major problems.
 
> > Users suggest and submit enhancement ideas -- sometimes fully coded.
>
> Nobody ever submitted me anything that could be thought of as a
> progressive step towards the two major redesigns I've done
> (Boost.Python and Boost.Iterators). The redesigns took a great deal
> of imagination, the sort of thinking that someone who's just trying
> to get his own work done can't really afford to do.

Fair enough, but there have been major submissions for other libraries -- some
more radical than others. I know there have been user submissions for design
changes related to signals performance that Doug has been looking at. Perhaps
it's a question of what you and I define as 'major redesign'....

> > I haven't read every last word, of the reviews, but what I did read
> > seemed like a mostly healthy interchange of possible ideas and
> > limitations with various approaches.
>
> I don't understand why you're saying that. I made no judgement about
> the health of the conversation.

Well, my take was that Andreas was quite open to discussing the options and
directions that would lead to better performance. Others seem to think that
Andreas has closed off all viable options, but maybe I'm the one that's
misreading the conversation.

Jeff


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