From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-03-13 01:05:35
> | 1. Boost is about Excellency
> Agreed, but But "The Best is the Enemy of the Good".
> IMHO ALL designs are compromises (especially C++ itself!)
> and if we only accept perfection, and reject this (and others),
> we risk throwing the baby out with the bathwater.
1. We do not through anything anywhere. It's still there. Just does not
approved yet. It doesn't mean it's unusable. It just mean that community
think it's still is not good enough. You may argue that library wouldn't get
as good acceptance from managerial level (since it's not covered by Boost
label). My position is accepting library that community think is not good
enough yet has even worse consequences: eventually level of trust to the
label will decline affecting all libraries.
2. I personally am not quite sure the baby exist in this case.
I have extensive recent experience with applying FSM based logic to
performance important parts of several utilities. But unfortunately I did
not have a time and resources to invest into review for this submission. I
only read tutorial. I must say it left me .. well .. open-mouthed: Why would
anyone use solution like this?
1. All states are .. well .. stateless. no way to save anything into state -
it gets destroyed every time
2. I have to spend time every time on new, constructor, destructor for each
3. From what I see there is no way it could have constant dispatch time
(just guess - no real analysis - but I would be really surprised if it's not
4. Interface limitations seems unreasonable: why would deferred event needs
to be supplied as intrusive_ptr?
Keep in mind that is just my opinion after perfunctory look on tutorial.
> | 4. In numerous case attempts to address any major issues
> | results in complete new interface/design/implementation.
> So what - there aren't going to be too many things depending on it
> -- unlike string and serialization.
I am not sure why you believe this is true.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk