Jody Hagins <jody-boost-011304@atdesk.com> 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