From: David Abrahams (dave_at_[hidden])
Date: 2005-03-06 03:36:39
Jody Hagins <jody-boost-011304_at_[hidden]> writes:
>> If this library is accepted into boost I will
>> continue building my FSM by hand, use Alexsey's FSM, or SMC or even
>> boost function.
> I will not use it either, mainly due to the overhead. This library is
> easier to use than my current implementations, but the overhead is way
> too much for me to consider using it in my production code.
> However, I do not know that I would vote against it, based on the idea
> that it is not useful to me. On the other hand, I would not vote *for*
> it either. Maybe my feeling/reaction is in some way related to David's
> concern about the acceptance process...
IMO someone like you probably *should* vote against it, especially if
you've taken the time to do reasonable review. At least you have a
real-world need for FSMs. I just "know" that FSMs are sometimes used
for lightweight speed-critical components. Or maybe more people
should be voting for it on the *condition* that an option with fast
dispatch must be available. I must say, in a world replete with
high-performance generic components, I agree that "Boost FSM" is too
broad to cover a library that only does dynamic double-dispatch.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk