Hi Franz,
SC 19.63630 s Rhapsody 4.95109 s MSM 0.90754 s
Thanks for the review and for the very interesting comparison with Rhapsody, which I found impressive for several reasons: - Rhapsody is, I think, a pretty costly tool (I heard 15k€) so I expected some cool fsm framework and instead the event dispatching really is just a simple switch on states of if/else on event ids, so a pretty basic implementation (though it would be interesting to see how more complicated machines are generated). Of course, as it is made for embedded development, this is understandable. - although this is such basic C-like implementation, Msm is 5 times faster. This is fascinating, the rootState_processEvent is so simple, one can wonder how it is possible to be faster. I find this a good example of the power of metaprogramming. I love C++ :) Thanks, Christophe
On Dec 3, 2009, at 2:58 PM, Christophe Henry wrote:
Hi Franz,
SC 19.63630 s Rhapsody 4.95109 s MSM 0.90754 s
Thanks for the review and for the very interesting comparison with Rhapsody, which I found impressive for several reasons: - Rhapsody is, I think, a pretty costly tool (I heard 15k€) so I expected some cool fsm framework and instead the event dispatching really is just a simple switch on states of if/else on event ids, so a pretty basic implementation (though it would be interesting to see how more complicated machines are generated). Of course, as it is made for embedded development, this is understandable. - although this is such basic C-like implementation, Msm is 5 times faster. This is fascinating, the rootState_processEvent is so simple, one can wonder how it is possible to be faster. I find this a good example of the power of metaprogramming.
I have two (harsh?) questions to this community: 1. Is there a Boost library removal process, so that one can at least mark a library as deprecated? The duality, sort of, to the acceptance process. 2. *If* (i) MSM were part of Boost before Statechart and (ii) compilers could handle massive transition tables (in the order of a few hundred transitions), would Statechart have been accepted?
I love C++ :)
I am certain that C++ loves you back, Cristophe. /David
David Bergman wrote:
On Dec 3, 2009, at 2:58 PM, Christophe Henry wrote: I have two (harsh?) questions to this community:
1. Is there a Boost library removal process, so that one can at least mark a library as deprecated? The duality, sort of, to the acceptance process.
There isn't - and there shouldn't be. Once one employs a library in a real program, he has to be sure that it's going to be around an indefinate amount of time. Otherwise, the maintainence of the application which uses it isn't under control of application developer anymore. One could suggest that there be a process of "recommendation" but that's going to be pretty subjective. I think this should be handled in a way that boost doesn't currently provide for.
2. *If* (i) MSM were part of Boost before Statechart and (ii) compilers could handle massive transition tables (in the order of a few hundred transitions), would Statechart have been accepted?
I don't think the answer to that question is relevant to anything. Personally I don't see any problem in having more than one library address the same problem as long as they are different in some substantive way.
I love C++ :)
I'm sure we all do.
I am certain that C++ loves you back, Cristophe.
I'm not so certain about this at least in my personal case. Robert Ramey
On Dec 3, 2009, at 5:08 PM, Robert Ramey wrote:
David Bergman wrote:
On Dec 3, 2009, at 2:58 PM, Christophe Henry wrote: I have two (harsh?) questions to this community:
1. Is there a Boost library removal process, so that one can at least mark a library as deprecated? The duality, sort of, to the acceptance process.
There isn't - and there shouldn't be. Once one employs a library in a real program, he has to be sure that it's going to be around an indefinate amount of time. Otherwise, the maintainence of the application which uses it isn't under control of application developer anymore.
One could suggest that there be a process of "recommendation" but that's going to be pretty subjective. I think this should be handled in a way that boost doesn't currently provide for.
2. *If* (i) MSM were part of Boost before Statechart and (ii) compilers could handle massive transition tables (in the order of a few hundred transitions), would Statechart have been accepted?
I don't think the answer to that question is relevant to anything.
To anything, really? In fact, a hypothetical positive answer to that question would indicate that MSM is as good or better*, ignoring compiler limitations. Come on, folks, let us face it: we are about to have two *very* similar FSM libraries here, so it should be fair to ask whether one is - feature-wise - better* than the other. No? We do not have this much overlap in any other library w.r.t. features and interface. We have the Spirit/Regex overlap, but that overlap is only partial, and Spirit handles more while Regex handles the intersection (arguably) in a simpler manner. Definitely simpler for developers not used to embedded DSLs in C++. * - yes, I did use a subjective term
Personally I don't see any problem in having more than one library address the same problem as long as they are different in some substantive way.
I love C++ :)
I'm sure we all do.
I am certain that C++ loves you back, Cristophe.
I'm not so certain about this at least in my personal case.
We have had our problems over the years, with a lot of fights about proper anonymous object creation (and destruction) and some heated arguments about NVO. /David
We do not have this much overlap in any other library w.r.t. features and interface.
What about Regex and Xpressive? I know neither of these libraries well, but doesn't Xpressive offer what Regex offers and more? -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
On Dec 3, 2009, at 6:27 PM, Andreas Huber wrote:
We do not have this much overlap in any other library w.r.t. features and interface.
What about Regex and Xpressive? I know neither of these libraries well, but doesn't Xpressive offer what Regex offers and more?
Actually, I meant to include the triplet Regex, Spirit and Xpressive in my discussion about the closest case to the Statechart/MSM situation. Since Xpressive - conceptually - solves the problems of both Regex and Spirit, one could argue that it would be the only one needed in this triplet. BUT, the interface to regular expressions (and regular languages) is quite different between Xpressive and Regex and the latter conforms more to the Perl+GNU-style API's of dealing with regular expressions. If I were king of the world (...), I would standardize on Xpressive and deprecate both Spirit and Regex, *with regards to* interface and features (and not implementation.) Regex is obviously easier to wrap around a proven and efficient implementation such as PCRE, and is easier to inject in C++0x... It is no coincidence that Xpressive came after Spirit and Regex. In fact, I have had to explain - and justify - this triplet to new Boosters in my teams. But, we here have different interfaces and different problems (or languages to parse): regular vs context-free vs both. For less DSLish developers, Regex is the clear choice for regular expressions. But, I have managed to convert a few people to become DSL:ers, and am planning to open their eyes to Proto; once they get hooked on DSL, they love Spirit and Xpressive. /David
On Thu, Dec 3, 2009 at 6:18 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
On Dec 3, 2009, at 6:27 PM, Andreas Huber wrote:
We do not have this much overlap in any other library w.r.t. features and interface.
What about Regex and Xpressive? I know neither of these libraries well, but doesn't Xpressive offer what Regex offers and more?
Actually, I meant to include the triplet Regex, Spirit and Xpressive in my discussion about the closest case to the Statechart/MSM situation.
Since Xpressive - conceptually - solves the problems of both Regex and Spirit, one could argue that it would be the only one needed in this triplet. BUT, the interface to regular expressions (and regular languages) is quite different between Xpressive and Regex and the latter conforms more to the Perl+GNU-style API's of dealing with regular expressions.
If I were king of the world (...), I would standardize on Xpressive and deprecate both Spirit and Regex, *with regards to* interface and features (and not implementation.) Regex is obviously easier to wrap around a proven and efficient implementation such as PCRE, and is easier to inject in C++0x...
It is no coincidence that Xpressive came after Spirit and Regex.
In fact, I have had to explain - and justify - this triplet to new Boosters in my teams. But, we here have different interfaces and different problems (or languages to parse): regular vs context-free vs both. For less DSLish developers, Regex is the clear choice for regular expressions. But, I have managed to convert a few people to become DSL:ers, and am planning to open their eyes to Proto; once they get hooked on DSL, they love Spirit and Xpressive.
Actually Spirit and Xpressive have different domains. Xpressive is a regex parser, suited for regex stuff, *not* suited for parsing a language. Spirit is a PEG parser, suited for parsing complex things, not always suited for regex stuff, they actually have little overlap.
On Dec 3, 2009, at 9:22 PM, OvermindDL1 wrote:
On Thu, Dec 3, 2009 at 6:18 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
On Dec 3, 2009, at 6:27 PM, Andreas Huber wrote:
We do not have this much overlap in any other library w.r.t. features and interface.
What about Regex and Xpressive? I know neither of these libraries well, but doesn't Xpressive offer what Regex offers and more?
Actually, I meant to include the triplet Regex, Spirit and Xpressive in my discussion about the closest case to the Statechart/MSM situation.
Since Xpressive - conceptually - solves the problems of both Regex and Spirit, one could argue that it would be the only one needed in this triplet. BUT, the interface to regular expressions (and regular languages) is quite different between Xpressive and Regex and the latter conforms more to the Perl+GNU-style API's of dealing with regular expressions.
If I were king of the world (...), I would standardize on Xpressive and deprecate both Spirit and Regex, *with regards to* interface and features (and not implementation.) Regex is obviously easier to wrap around a proven and efficient implementation such as PCRE, and is easier to inject in C++0x...
It is no coincidence that Xpressive came after Spirit and Regex.
In fact, I have had to explain - and justify - this triplet to new Boosters in my teams. But, we here have different interfaces and different problems (or languages to parse): regular vs context-free vs both. For less DSLish developers, Regex is the clear choice for regular expressions. But, I have managed to convert a few people to become DSL:ers, and am planning to open their eyes to Proto; once they get hooked on DSL, they love Spirit and Xpressive.
Actually Spirit and Xpressive have different domains. Xpressive is a regex parser, suited for regex stuff, *not* suited for parsing a language. Spirit is a PEG parser, suited for parsing complex things, not always suited for regex stuff, they actually have little overlap.
Yeah, I was exaggerating the commonalities a bit (between Xpressive and Spirit) - although it is possible to create parsers for toy languages in Xpressive. I did that partly to question the validity of my own point: that the MSM/Statechart overlap is a unique situation for Boost :-) Repeating: the MSM/Statechart overlap in features and interface is quite unique to Boost. I argue that this is a bad thing. "You can never get too many goodies!" Well, I think you can. Is that situation bad enough not to be outweighed by the quite terrific design of MSM? Probably not, but I just wanted to raise the general question of duplicity (and redundancy), and also that of potentially deprecating libraries. Boost has always been "one problem aspect --- one tool" to encourage the developer to mix such specific (often orthogonal) tools into complete solutions. Yes, I know that the the epimorphic direction of that relationship is the one we have focused on mainly, but I argue that even the monomorphic direction is important, i.e., that there is exactly one solution to one *specific* problem aspect. /David
On Thu, Dec 3, 2009 at 7:54 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
On Dec 3, 2009, at 9:22 PM, OvermindDL1 wrote:
On Thu, Dec 3, 2009 at 6:18 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
On Dec 3, 2009, at 6:27 PM, Andreas Huber wrote:
We do not have this much overlap in any other library w.r.t. features and interface.
What about Regex and Xpressive? I know neither of these libraries well, but doesn't Xpressive offer what Regex offers and more?
Actually, I meant to include the triplet Regex, Spirit and Xpressive in my discussion about the closest case to the Statechart/MSM situation.
Since Xpressive - conceptually - solves the problems of both Regex and Spirit, one could argue that it would be the only one needed in this triplet. BUT, the interface to regular expressions (and regular languages) is quite different between Xpressive and Regex and the latter conforms more to the Perl+GNU-style API's of dealing with regular expressions.
If I were king of the world (...), I would standardize on Xpressive and deprecate both Spirit and Regex, *with regards to* interface and features (and not implementation.) Regex is obviously easier to wrap around a proven and efficient implementation such as PCRE, and is easier to inject in C++0x...
It is no coincidence that Xpressive came after Spirit and Regex.
In fact, I have had to explain - and justify - this triplet to new Boosters in my teams. But, we here have different interfaces and different problems (or languages to parse): regular vs context-free vs both. For less DSLish developers, Regex is the clear choice for regular expressions. But, I have managed to convert a few people to become DSL:ers, and am planning to open their eyes to Proto; once they get hooked on DSL, they love Spirit and Xpressive.
Actually Spirit and Xpressive have different domains. Xpressive is a regex parser, suited for regex stuff, *not* suited for parsing a language. Spirit is a PEG parser, suited for parsing complex things, not always suited for regex stuff, they actually have little overlap.
Yeah, I was exaggerating the commonalities a bit (between Xpressive and Spirit) - although it is possible to create parsers for toy languages in Xpressive. I did that partly to question the validity of my own point: that the MSM/Statechart overlap is a unique situation for Boost :-)
Repeating: the MSM/Statechart overlap in features and interface is quite unique to Boost. I argue that this is a bad thing. "You can never get too many goodies!" Well, I think you can. Is that situation bad enough not to be outweighed by the quite terrific design of MSM? Probably not, but I just wanted to raise the general question of duplicity (and redundancy), and also that of potentially deprecating libraries.
Boost has always been "one problem aspect --- one tool" to encourage the developer to mix such specific (often orthogonal) tools into complete solutions. Yes, I know that the the epimorphic direction of that relationship is the one we have focused on mainly, but I argue that even the monomorphic direction is important, i.e., that there is exactly one solution to one *specific* problem aspect.
I actually love more libraries, even if similar, as long as they are well designed, but I would prefer if they were merged. Even in my template code I tend to have help functors specified in template params, but people can override those, and I have a variant (or base class in some situations) so that they can choose at runtime. There are interesting little ways to combine everything, certainly the usages of StateChart and MSM can be combined in some way, if not, I still see no problem to have both *AS*LONG*AS* both the pros and cons of each are listed in *both* of their documentations (the same reasons in both, so there can be no chance of bias).
On Fri, Dec 4, 2009 at 10:54 AM, David Bergman < David.Bergman@bergmangupta.com> wrote:
Repeating: the MSM/Statechart overlap in features and interface is quite unique to Boost.
They definitely overlap in features and also in intent, but my understanding is that the interfaces are vastly different, and that's an important distinguishing feature. Am I missing something? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Bergman wrote:
Repeating: the MSM/Statechart overlap in features and interface is quite unique to Boost. I argue that this is a bad thing. "You can never get too many goodies!" Well, I think you can. Is that situation bad enough not to be outweighed by the quite terrific design of MSM? Probably not, but I just wanted to raise the general question of duplicity (and redundancy), and also that of potentially deprecating libraries.
Back in the mid to late 90's I worked closely with a company called ObjecTime [1]. They were a telco spin-off that promoted a tool set and methodology called ROOM (Real-time Object Oriented Modeling). ROOM was very successful to the point that the ObjecTime/IBM's submission to OMG was about to be accepted as *the* real-time modeling language. Rational was distraught and quickly purchased a controlling stake of ObjecTime and integrated ROOM as the first release of UML for Real-time. What does all of this have to do with MSM/Statechart overlap? Even ObjecTime saw that not all FSM implementation/designs are created equal. While the "front end" modeling concepts provided a rich language that we could apply to various problem domains, not all domains have the same design/implementation requirements. A profitable, resource-conscience company made the choice to provide multiple FSM libraries implementing the same modeling concepts because it made good sense. I have my own graphical tool/code generator based heavily on ROOM and UML. I have considered SC and MSM as additional backend offerings to my own FSM libraries. SC is a non-starter for many of my (and my clients') targets with very small stack space. Constant creation/destruction of state objects makes me seriously question the viability of that approach for those targets. I have some small concern about the final build size of MSM; however, creating a machine in global space that is completely initialized on start-up fits perfectly with the requirements of those targets. On the other hand, some of my targets running actual OS's with real amounts of memory create and destroy actors dynamically and perform various nifty dynamic port bindings that are much more in-line with a design/implementation utilizing virtual functions and inheritance. SC might be the perfect choice for these targets. I have many other examples of why specifically different FSM's are appropriate for different targets... but this email is already much longer than I had intended. Interface variations make/break library adoption all the time. Design/implementation choices differentiate libraries for specific domains constantly. There is so much more than equivalent feature sets that make libraries "equivalent". Best regards - michael [1] http://en.wikipedia.org/wiki/ObjecTime -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On Dec 5, 2009, at 7:03 PM, Michael Caisse wrote:
David Bergman wrote:
Repeating: the MSM/Statechart overlap in features and interface is quite unique to Boost. I argue that this is a bad thing. "You can never get too many goodies!" Well, I think you can. Is that situation bad enough not to be outweighed by the quite terrific design of MSM? Probably not, but I just wanted to raise the general question of duplicity (and redundancy), and also that of potentially deprecating libraries.
Back in the mid to late 90's I worked closely with a company called ObjecTime [1]. They were a telco spin-off that promoted a tool set and methodology called ROOM (Real-time Object Oriented Modeling). ROOM was very successful to the point that the ObjecTime/IBM's submission to OMG was about to be accepted as *the* real-time modeling language. Rational was distraught and quickly purchased a controlling stake of ObjecTime and integrated ROOM as the first release of UML for Real-time. What does all of this have to do with MSM/Statechart overlap? Even ObjecTime saw that not all FSM implementation/designs are created equal. While the "front end" modeling concepts provided a rich language that we could apply to various problem domains, not all domains have the same design/implementation requirements. A profitable, resource-conscience company made the choice to provide multiple FSM libraries implementing the same modeling concepts because it made good sense. I have my own graphical tool/code generator based heavily on ROOM and UML. I have considered SC and MSM as additional backend offerings to my own FSM libraries. SC is a non-starter for many of my (and my clients') targets with very small stack space. Constant creation/destruction of state objects makes me seriously question the viability of that approach for those targets. I have some small concern about the final build size of MSM; however, creating a machine in global space that is completely initialized on start-up fits perfectly with the requirements of those targets.
On the other hand, some of my targets running actual OS's with real amounts of memory create and destroy actors dynamically and perform various nifty dynamic port bindings that are much more in-line with a design/implementation utilizing virtual functions and inheritance. SC might be the perfect choice for these targets.
I have many other examples of why specifically different FSM's are appropriate for different targets... but this email is already much longer than I had intended. Interface variations make/break library adoption all the time. Design/implementation choices differentiate libraries for specific domains constantly. There is so much more than equivalent feature sets that make libraries "equivalent".
Heh, yes. I have probably used dozens of implementation of each "feature set" (regex, BNF, DFA, hash tables, other trees, graphs); but, here we are about to have two rivaling - for a lot of use cases - libraries filling the same purpose within our meta library. A clearly interesting situation. And, yes, the way to use Statechart and MSM are *much more* similar compared to Regex vs Xpressive :-) Look at my other post, containing a trivial state machine under both Statechart and MSM, and you will see that even from an interface POV, they are fairly similar. Implementation-wise they are quite different, as you noted. In fact, MSM is around six times faster than Statechart in almost all my sample scenarios, where Statechart, for instance, consumes a lot of time inside dynamic_cast. Well, I hope to remember all these points for my review of MSM :-) /David
On 12/03/2009 04:27 PM, Andreas Huber wrote:
We do not have this much overlap in any other library w.r.t. features and interface.
What about Regex and Xpressive? I know neither of these libraries well, but doesn't Xpressive offer what Regex offers and more?
I would not say so. Xpressive's static regexes are "odd". It's hard enough to master regular expression -- mastering a new, C++-specific DSL for regexes is just brain damage. And its dynamic regexes are (based solely on comparing the documentation and my use of Regex) not as featureful as those in Regex.
Rob Riggs wrote:
It's hard enough to master regular expression -- mastering a new, C++-specific DSL for regexes is just brain damage.
Perhaps it's just me, but I find the Xpressive DSL much easier to work with than Perl-style expressions, especially when trying to figure out what someone else's regex actually does. But I think that just adds to the point -- Regex and Xpressive are quite different. --Jeffrey Bosboom
Andreas Huber wrote:
We do not have this much overlap in any other library w.r.t. features and interface.
What about Regex and Xpressive? I know neither of these libraries well, but doesn't Xpressive offer what Regex offers and more?
I think an even better example would be map and hash_map. They serve almost identical purpose but using totally different techniques. The user of stl is expected to understand the differences and chose the appropriate container. Why not do the same with SC and MSM?
David Bergman wrote:
To anything, really? In fact, a hypothetical positive answer to that question would indicate that MSM is as good or better*, ignoring compiler limitations. Come on, folks, let us face it: we are about to have two *very* similar FSM libraries here, so it should be fair to ask whether one is - feature-wise - better* than the other. No? We do not have this much overlap in any other library w.r.t. features and interface. We have the Spirit/Regex overlap, but that overlap is only partial, and Spirit handles more while Regex handles the intersection (arguably) in a simpler manner. Definitely simpler for developers not used to embedded DSLs in C++.
* - yes, I did use a subjective term
This seems much like the discussion just had exhaustively about the geometry libraries, and I don't suspect that it will be anymore fruitful. I, for one, wouldn't mind skipping it if it's all the same to anyone else! <grin;> best regards, Patrick
Hi David
1. Is there a Boost library removal process, so that one can at least mark a library as deprecated? The duality, sort of, to the acceptance process.
Remove libraries? Current users of the to be removed library would be delighted to learn that their code will no longer compile with the next version of Boost. Deprecated libraries? Seems like a good idea, if the new library offers a strict superset of the features of the old one. In reality this will almost never happen.
2. *If* (i) MSM were part of Boost before Statechart and (ii) compilers could handle massive transition tables (in the order of a few hundred transitions), would Statechart have been accepted?
Probably not, but why is this important? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
On Dec 3, 2009, at 6:17 PM, Andreas Huber wrote:
Hi David
1. Is there a Boost library removal process, so that one can at least mark a library as deprecated? The duality, sort of, to the acceptance process.
Remove libraries? Current users of the to be removed library would be delighted to learn that their code will no longer compile with the next version of Boost. Deprecated libraries? Seems like a good idea, if the new library offers a strict superset of the features of the old one. In reality this will almost never happen.
Well, that is the case with Spirit 1 and Spirit 2, right?
2. *If* (i) MSM were part of Boost before Statechart and (ii) compilers could handle massive transition tables (in the order of a few hundred transitions), would Statechart have been accepted?
Probably not, but why is this important?
How do you think it feels for new Boost users to encounter two libraries with virtually identical use and interface? I think that is a bad thing in itself, and makes Boost look less coherent. I.e., if these two libraries were up for review now, would we accept them both? My team members and colleagues that are new to Boost, will ask me why 1.43 has two virtually identical - feature-wise - libraries handling state machines. I do not want to tell them "why do you care?" Well, well, I seem to be the only one caring about this, and MSM sure is a fine library, so I say 'welcome metamagical states!'. NOTE: no, this was not a formal review ;-) /David
David Bergman wrote:
How do you think it feels for new Boost users to encounter two libraries with virtually identical use and interface? I think that is a bad thing in itself, and makes Boost look less coherent.
Your point seems to be that there should only be one library for a given task because users will be confused when you ask them to choose one based on their merits. While I think it's a valid point, I don't think it's a good enough reason to reject a library or to remove an existing library. After all, the C++ language itself gives the programmer a lot of choices for accomplishing basically the same task. But I think this concern can be addressed if there is a documentation page that compares the libraries that is included in (or linked from) both libraries' documentation. This would make it much easier for a user to choose one or the other without having to read the full documentation for each.
I.e., if these two libraries were up for review now, would we accept them both?
Probably not, but we can't drop support for an existing library, at least without a deprecation period (and preferably an interface adaptor that will allow code written against the old library to run using the new one). The other option would be to reject MSM because Statechart has already been accepted, and I think that would be a bad idea as well. Decide whether MSM should be included or not on its own merits. If so, then MSM makes Boost better; we shouldn't be so concerned with being perfect that we lose the opportunity to be better. --Jeffrey Bosboom
On Dec 3, 2009, at 11:39 PM, Jeffrey Bosboom wrote:
David Bergman wrote:
How do you think it feels for new Boost users to encounter two libraries with virtually identical use and interface? I think that is a bad thing in itself, and makes Boost look less coherent.
Your point seems to be that there should only be one library for a given task because users will be confused when you ask them to choose one based on their merits. While I think it's a valid point, I don't think it's a good enough reason to reject a library or to remove an existing library. After all, the C++ language itself gives the programmer a lot of choices for accomplishing basically the same task.
But the choices are usually, well, *different* ways (different notions or at least highly different interfaces) of accomplishing the same thing. The biggest difference from a (developer's) usability point of view between MSM and Statechart seems to the expression of the transition table. In fact, when thinking about how to simplify the transition table expression further, I would even have welcomed some macros that introduce the state declarations for simplistic states, from that transition table expression.
But I think this concern can be addressed if there is a documentation page that compares the libraries that is included in (or linked from) both libraries' documentation. This would make it much easier for a user to choose one or the other without having to read the full documentation for each.
I.e., if these two libraries were up for review now, would we accept them both?
Probably not, but we can't drop support for an existing library, at least without a deprecation period (and preferably an interface adaptor that will allow code written against the old library to run using the new one). The other option would be to reject MSM because Statechart has already been accepted, and I think that would be a bad idea as well.
Decide whether MSM should be included or not on its own merits. If so, then MSM makes Boost better; we shouldn't be so concerned with being perfect that we lose the opportunity to be better.
You have a good point there. Although I would rather have seen the MSM guys collaborate with the Statechart guys on making Statechart easier to use (especially the expression of the transition table) and/or more performant, though. If that would have led to a combined Statechart 2.0 (analogous to Spirit 2.0) in a year, I would wait. /David "Grumpy Old Man" Bergman
David Bergman wrote: <snip>
But the choices are usually, well, *different* ways (different notions or at least highly different interfaces) of accomplishing the same thing.
What about map and hash_map? They try to accomplish the same thing and the interfaces are almost identical? I say make the user aware of different options and what the differences mean in terms of performance/scalability/usability and so on and let her decide what to use.
On Dec 4, 2009, at 12:20 AM, Andrew Venikov wrote:
David Bergman wrote: <snip>
But the choices are usually, well, *different* ways (different notions or at least highly different interfaces) of accomplishing the same thing.
What about map and hash_map? They try to accomplish the same thing and the interfaces are almost identical?
Or even std::vector and std::list for a lot of operations :-) Yes, if the runtime characteristics is highly distinct, preferably complexity-theoretically so, there can be a use of multiple implementations. Although: even the notions at a *semi*-abstract level are different between map (tree) and hash_map (); so, I do not even think about hash_map and map the same when diving an inch below the most abstract level. So, I would venture to say that the notions are distinct at that semi-abstract level.
I say make the user aware of different options and what the differences mean in terms of performance/scalability/usability and so on and let her decide what to use.
Makes sense. This will become quite important, as some other guys have pointed out. /David
You have a good point there. Although I would rather have seen the MSM guys collaborate with the Statechart guys on making Statechart easier to use (especially the expression of the transition table) and/or more performant, though.
MSM and Statechart assumptions and resulting implementations are so fundamentally different that merging the two libraries would IMO not be feasible. The result would most likely not be a very coherent interface. In other words, I don't think there can be a single best answer to "How do I implement a state machine in C++?". The requirements are just too varied. The main areas where I see conflict are: 1) Scalability: An MSM statemachine must be implemented in one TU, a Statechart statemachine can be spread over multiple TUs 2) State-local storage: In Statechart, storage only exists while a state is active. In MSM storage exists for the whole duration of the statemachine lifetime So, even if Christophe had asked me whether I'd want to collaborate on Statechart 2.0, I'd probably have declined. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
On Fri, 2009-12-04 at 13:53 +0100, Andreas Huber wrote:
1) Scalability: An MSM statemachine must be implemented in one TU, a Statechart statemachine can be spread over multiple TUs 2) State-local storage: In Statechart, storage only exists while a state is active. In MSM storage exists for the whole duration of the statemachine lifetime
I agree with this. However, I have yet to come completely to terms with how best to use msm. I am beginning to think, in trying to use it, that it would be better to separate the state transition table definition as much as possible from what, in an msm world, are more like semantic actions. This is very different from the more oo modeling approach of statechart. I'm not sure the statechart isn't better at expressing fsms that "emerge" out of overall application/system design in an all encompassing oo design uml world, and msm better at expressing more self contained "islands" of fsm in an app. I'm far from an expert with spirit, but I think there are many concepts that could be borrowed from it to make msm better able to be used to define a fsm that can be bound to separate objects to implement behavior and exend its use beyond these islands. Basically, it needs to be easier to take a 1 TU transition table integrate it into to a bigger multi TU system. To this end, it would be helpful if msm defined some very clear and minimal concepts for those entities it deals with: events - msm doesn't really care what the event is - it just needs a type. Probably nothing to define here... actions - the functor approach is good - though it needs a bit more development to make it easier to bind to actions that are not explicitly designed for use as msm state machine actions. guards - see actions... states - I don't really understand what an instance of a state is in msm - it doesn't model anything meaningful to me. This is unlike statechart, where the idea of object instantiation as state is genuinely useful - sometimes, and where it is the state that "reacts" to an event. Should msm drop state objects altogether and simply have some sort of context / current state object? Arguably it already has one in the form of the fsm object - though that is a bigger concept than context. Michael Caisse has already pointed out that there is something slightly odd about the current state being represented as a scalar in a model that has objects as states. I haven't spent much time thinking about this, but I feel it is this machine/context concept that needs work to make extending the fsm easier.
David Bergman wrote:
How do you think it feels for new Boost users to encounter two libraries with virtually identical use and interface? I think that is a bad thing in itself, and makes Boost look less coherent. I.e., if these two libraries were up for review now, would we accept them both?
This was discussed just recently in the two geometry library reviews (both accepted) and the majority view was that it is a good thing to have many libraries even if they overlap. Phil.
On Dec 4, 2009, at 7:37 AM, Phil Endecott wrote:
David Bergman wrote:
How do you think it feels for new Boost users to encounter two libraries with virtually identical use and interface? I think that is a bad thing in itself, and makes Boost look less coherent. I.e., if these two libraries were up for review now, would we accept them both?
This was discussed just recently in the two geometry library reviews (both accepted) and the majority view was that it is a good thing to have many libraries even if they overlap.
MSM and Statechart do not merely overlap, the do the exact same thing: letting the developer specify and execute a state machine. /David
MSM and Statechart do not merely overlap, the do the exact same thing: letting the developer specify and execute a state machine.
This statement is about as ignorant of the details as: "std::list<> and std::vector<> do not merely overlap, they do the exact same thing: letting the developer store objects in memory" -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
On Dec 5, 2009, at 6:01 AM, Andreas Huber wrote:
MSM and Statechart do not merely overlap, the do the exact same thing: letting the developer specify and execute a state machine.
This statement is about as ignorant of the details as: "std::list<> and std::vector<> do not merely overlap, they do the exact same thing: letting the developer store objects in memory"
Ignorant? Andreas, I can tell you one thing: I am anything but ignorant. Do you claim that I am wrong, i.e., that either MSM or Statechart does something else but letting the developer specify and execute a state machine? Do you realize that this specific use is much less generic than your "store objects in memory"? This is not the kind of comment that will sway me, that is for sure. The abstraction - FSM - is very *specific* and is common between MSM and Statechart. /David
On Dec 5, 2009, at 9:35 AM, David Bergman wrote:
On Dec 5, 2009, at 6:01 AM, Andreas Huber wrote:
MSM and Statechart do not merely overlap, the do the exact same thing: letting the developer specify and execute a state machine.
This statement is about as ignorant of the details as: "std::list<> and std::vector<> do not merely overlap, they do the exact same thing: letting the developer store objects in memory"
Ignorant? Andreas, I can tell you one thing: I am anything but ignorant. Do you claim that I am wrong, i.e., that either MSM or Statechart does something else but letting the developer specify and execute a state machine? Do you realize that this specific use is much less generic than your "store objects in memory"?
This is not the kind of comment that will sway me, that is for sure. The abstraction - FSM - is very *specific* and is common between MSM and Statechart.
Furthermore, I detailed in another post that what would be required is a radical difference in either (i) use (interface...) of the FSM and/or (ii) runtime characteristics (such as the difference in implementation strategy between map and hash_map, or list and vector in features they both share - sequences of objects.) There *is* a quite significant difference in runtime characteristics between Statechart and MSM, as far as I can tell, and hopefully that would be put high up in the rationale or overview of both MSM and Statechart in Boost 1.44 (or whatever.) There is no ignorance of complexity issues here, but at a certain abstract level - which happens not to be quite *specific* - these two libraries do the same thing. /David
Ugh, s/not to be quite \*specific\*/to be quite \*narrow\*/ It is sad that my comments are construed as criticism of MSM, since they merely point out the (I thought obvious...) similarities with another library already in Boost. After having tried MSM for a few days, most of it rocks, and I will provide a review later today. /David On Dec 5, 2009, at 9:44 AM, David Bergman wrote:
On Dec 5, 2009, at 9:35 AM, David Bergman wrote:
On Dec 5, 2009, at 6:01 AM, Andreas Huber wrote:
MSM and Statechart do not merely overlap, the do the exact same thing: letting the developer specify and execute a state machine.
This statement is about as ignorant of the details as: "std::list<> and std::vector<> do not merely overlap, they do the exact same thing: letting the developer store objects in memory"
Ignorant? Andreas, I can tell you one thing: I am anything but ignorant. Do you claim that I am wrong, i.e., that either MSM or Statechart does something else but letting the developer specify and execute a state machine? Do you realize that this specific use is much less generic than your "store objects in memory"?
This is not the kind of comment that will sway me, that is for sure. The abstraction - FSM - is very *specific* and is common between MSM and Statechart.
Furthermore, I detailed in another post that what would be required is a radical difference in either (i) use (interface...) of the FSM and/or (ii) runtime characteristics (such as the difference in implementation strategy between map and hash_map, or list and vector in features they both share - sequences of objects.) There *is* a quite significant difference in runtime characteristics between Statechart and MSM, as far as I can tell, and hopefully that would be put high up in the rationale or overview of both MSM and Statechart in Boost 1.44 (or whatever.) There is no ignorance of complexity issues here, but at a certain abstract level - which happens not to be quite *specific* - these two libraries do the same thing.
/David _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Ignorant? Andreas, I can tell you one thing: I am anything but ignorant.
Ok, I'm listening. How well do you know Statechart? Have you read the tutorial? Have you read the rationale? -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
On Dec 5, 2009, at 12:32 PM, Andreas Huber wrote:
Ignorant? Andreas, I can tell you one thing: I am anything but ignorant.
Ok, I'm listening. How well do you know Statechart? Have you read the tutorial? Have you read the rationale?
I have used it in two medium-sized projects (one BitTorrent-like client and one real-time auction engine, to keep track of the state of individual auctions.) Unfortunately, I have only toyed around with MSM the last few days. I know that the details differ between MSM and Statechart. So, I am much more knowledgeable about Statechart than what I am about MSM. I am quite knowledgeable about the theory and applications of FSMs, though, after a pair of decades of having forced teams to make explicit the state machines that often reside there implicitly (or at least intrinsically in the problem.) But, over these years, when using C++, I have almost always used our own implementations of state machines. Dare I say this: it is not the most tricky notion to implement, if one (i) is not that worried about the performance (say, not that many hundred transitions per second) or (ii) in need of nested states; and, this I dare say: it is also a quite rewarding task and fun! Yes, I know that both Statechart and MSM care about these aspects, which have *mostly* been a non-concern for my applications. Honestly, the nested FSMs have often been implemented ad hoc ;-) /David
I have used it in two medium-sized projects (one BitTorrent-like client and one real-time auction engine, to keep track of the state of individual auctions.)
Ok.
But, over these years, when using C++, I have almost always used our own implementations of state machines. Dare I say this: it is not the most tricky notion to implement, if one (i) is not that worried about the performance (say, not that many hundred transitions per second) or (ii) in need of nested states; and, this I dare say: it is also a quite rewarding task and fun!
Yes, I know that both Statechart and MSM care about these aspects, which have *mostly* been a non-concern for my applications. Honestly, the nested FSMs have often been implemented ad hoc ;-)
So I guess for the use cases you encountered, I doesn't make much difference whether you'd use MSM or Statechart, right? -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
On Dec 5, 2009, at 5:19 PM, Andreas Huber wrote:
I have used it in two medium-sized projects (one BitTorrent-like client and one real-time auction engine, to keep track of the state of individual auctions.)
Ok.
But, over these years, when using C++, I have almost always used our own implementations of state machines. Dare I say this: it is not the most tricky notion to implement, if one (i) is not that worried about the performance (say, not that many hundred transitions per second) or (ii) in need of nested states; and, this I dare say: it is also a quite rewarding task and fun!
Yes, I know that both Statechart and MSM care about these aspects, which have *mostly* been a non-concern for my applications. Honestly, the nested FSMs have often been implemented ad hoc ;-)
So I guess for the use cases you encountered, I doesn't make much difference whether you'd use MSM or Statechart, right?
Exactly. I want to find cases where it *does* matter, so I can justify another SFM library in Boost. I have tried the last few days to create toy-but-real-time apps with high load to see what gives. /David
So I guess for the use cases you encountered, I doesn't make much difference whether you'd use MSM or Statechart, right?
Exactly. I want to find cases where it *does* matter, so I can justify another SFM library in Boost. I have tried the last few days to create toy-but-real-time apps with high load to see what gives.
Ok then, but you do realize that your original statement ...
MSM and Statechart do not merely overlap, the do the exact same thing: letting the developer specify and execute a state machine.
... does come across as pretty universal? I mean there's no headroom here like "For my use cases ..." or "To me ...". In absence of such qualifiers the reader must assume that you think that from a purely functional POV the two libraries are exchangeable for *all* possible uses. Add your remarks regarding library removal and the reader must IMO come to the conclusion that you think *all* users will be better served with MSM once compilers catch up. For sure, MSM *does* look terrific and may well satisfy a good majority of FSM implementers but there are certain use cases (e.g. multi-TU FSMs) that MSM will probably never support. OTOH, Statechart will e.g. never be able to guarantee O(1) dispatch. So yes, there *is* overlap but it is certainly far from total, right? -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
On Dec 6, 2009, at 4:51 AM, Andreas Huber wrote:
So I guess for the use cases you encountered, I doesn't make much difference whether you'd use MSM or Statechart, right?
Exactly. I want to find cases where it *does* matter, so I can justify another SFM library in Boost. I have tried the last few days to create toy-but-real-time apps with high load to see what gives.
Ok then, but you do realize that your original statement ...
MSM and Statechart do not merely overlap, the do the exact same thing: letting the developer specify and execute a state machine.
... does come across as pretty universal?
First of all, sorry about the "SFM"... Yes. If either one of you had had a radically different approach to the representation of states, for instance as enums, or had used Boost.Signal for the events and/or actions, or one of the libraries did not support nested machines at all, then, yes, I could retract such a universal (is that a bad thing? ;-)) comment.
I mean there's no headroom here like "For my use cases ..." or "To me ...". In absence of such qualifiers the reader must assume that you think that from a purely functional POV the two libraries are exchangeable for *all* possible uses. Add your remarks regarding library removal and the reader must IMO come to the conclusion that you think *all* users will be better served with MSM once compilers catch up. For sure, MSM *does* look terrific and may well satisfy a good majority of FSM implementers but there are certain use cases (e.g. multi-TU FSMs) that MSM will probably never support. OTOH, Statechart will e.g. never be able to guarantee O(1) dispatch.
So yes, there *is* overlap but it is certainly far from total, right?
Not far from, no. If you bring up one feature, multi-TU FSM, I would not call that "far". The overlap is 95%. No? Just look at the feature list of your own library, Statechart, as described in the Overview section. Which one of those features does *not* apply to MSM? /David
David Bergman wrote:
I mean there's no headroom here like "For my use cases ..." or "To me ...". In absence of such qualifiers the reader must assume that you think that from a purely functional POV the two libraries are exchangeable for *all* possible uses. Add your remarks regarding library removal and the reader must IMO come to the conclusion that you think *all* users will be better served with MSM once compilers catch up. For sure, MSM *does* look terrific and may well satisfy a good majority of FSM implementers but there are certain use cases (e.g. multi-TU FSMs) that MSM will probably never support. OTOH, Statechart will e.g. never be able to guarantee O(1) dispatch.
So yes, there *is* overlap but it is certainly far from total, right?
Not far from, no. If you bring up one feature, multi-TU FSM, I would not call that "far". The overlap is 95%. No?
Just look at the feature list of your own library, Statechart, as described in the Overview section. Which one of those features does *not* apply to MSM?
/David
Just to be clear David... A couple people have now brought up that the actual implementation (not the feature set) is very much a differentiator for different targets. You continue to point at "features". Do you not think that the implementation of a library is a consideration for different targets? michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On Dec 6, 2009, at 4:28 PM, Michael Caisse wrote:
David Bergman wrote:
I mean there's no headroom here like "For my use cases ..." or "To me ...". In absence of such qualifiers the reader must assume that you think that from a purely functional POV the two libraries are exchangeable for *all* possible uses. Add your remarks regarding library removal and the reader must IMO come to the conclusion that you think *all* users will be better served with MSM once compilers catch up. For sure, MSM *does* look terrific and may well satisfy a good majority of FSM implementers but there are certain use cases (e.g. multi-TU FSMs) that MSM will probably never support. OTOH, Statechart will e.g. never be able to guarantee O(1) dispatch.
So yes, there *is* overlap but it is certainly far from total, right?
Not far from, no. If you bring up one feature, multi-TU FSM, I would not call that "far". The overlap is 95%. No?
Just look at the feature list of your own library, Statechart, as described in the Overview section. Which one of those features does *not* apply to MSM?
/David
Just to be clear David... A couple people have now brought up that the actual implementation (not the feature set) is very much a differentiator for different targets. You continue to point at "features". Do you not think that the implementation of a library is a consideration for different targets?
Yes, of course, which I have stated in various posts of mine. I *know* that the implementations differ, but that was not what we were discussing here, was it? We are discussing whether the feature sets and interfaces are far apart or not. /David
On Dec 6, 2009, at 4:39 PM, David Bergman wrote:
On Dec 6, 2009, at 4:28 PM, Michael Caisse wrote:
David Bergman wrote:
I mean there's no headroom here like "For my use cases ..." or "To me ...". In absence of such qualifiers the reader must assume that you think that from a purely functional POV the two libraries are exchangeable for *all* possible uses. Add your remarks regarding library removal and the reader must IMO come to the conclusion that you think *all* users will be better served with MSM once compilers catch up. For sure, MSM *does* look terrific and may well satisfy a good majority of FSM implementers but there are certain use cases (e.g. multi-TU FSMs) that MSM will probably never support. OTOH, Statechart will e.g. never be able to guarantee O(1) dispatch.
So yes, there *is* overlap but it is certainly far from total, right?
Not far from, no. If you bring up one feature, multi-TU FSM, I would not call that "far". The overlap is 95%. No?
Just look at the feature list of your own library, Statechart, as described in the Overview section. Which one of those features does *not* apply to MSM?
/David
Just to be clear David... A couple people have now brought up that the actual implementation (not the feature set) is very much a differentiator for different targets. You continue to point at "features". Do you not think that the implementation of a library is a consideration for different targets?
Yes, of course, which I have stated in various posts of mine.
I *know* that the implementations differ, but that was not what we were discussing here, was it? We are discussing whether the feature sets and interfaces are far apart or not.
Additionally, for targets (i) not having many transitions per second and/or (ii) not having severe memory (or compiler/standard library...) constraints, the run-time characteristics of these two libraries are good enough, i.e., the implementations would *not* be a differentiator when choosing an FSM library for future such Boost developers. I contend that this set of developers, or, rather problem domains, constitute the vast majority of FSMers. That contention might be wrong, and even if it were right, that would not make much difference to those (a) with high-frequency transitional needs (probably picking MSM) or (b) those with huge transition tables, crippled compilers or "crippled" deployment targets (I did not call them such when I worked much more with embedded development ;-)) (probably picking Statechart.) It is just for the "rest of us" that the choice would be much a matter of interfacial matters or even aesthetics :-) /David
David Bergman wrote:
Yes, of course, which I have stated in various posts of mine.
I *know* that the implementations differ, but that was not what we were discussing here, was it? We are discussing whether the feature sets and interfaces are far apart or not.
Could we move on? Patrick
On Dec 6, 2009, at 7:25 PM, Patrick Horgan wrote:
David Bergman wrote:
Yes, of course, which I have stated in various posts of mine.
I *know* that the implementations differ, but that was not what we were discussing here, was it? We are discussing whether the feature sets and interfaces are far apart or not.
Could we move on?
Oh, sorry. But when someone claims that I do not realize that the implementations differ, I have a hard time letting that lie. I do not enjoy people putting opinions in my virtual mouth. /David
David Bergman wrote:
On Dec 6, 2009, at 7:25 PM, Patrick Horgan wrote:
David Bergman wrote:
Yes, of course, which I have stated in various posts of mine.
I *know* that the implementations differ, but that was not what we were discussing here, was it? We are discussing whether the feature sets and interfaces are far apart or not.
Could we move on?
Oh, sorry. But when someone claims that I do not realize that the implementations differ, I have a hard time letting that lie. I do not enjoy people putting opinions in my virtual mouth.
/David _______________________________________________
I apologize David if it came across that way. I was simply trying to determine if you thought the implementation variations that distinguish a library's relevance to a target were important to the review. I've read all of your posts. I know that you can articulate the differences in implementation. I was just wondering if you thought that was an important distinguisher for Boost. As for moving on, I'm happy to do so (o; michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On Dec 7, 2009, at 1:28 AM, David Bergman wrote:
So yes, there *is* overlap but it is certainly far from total, right?
Not far from, no. If you bring up one feature, multi-TU FSM, I would not call that "far". The overlap is 95%. No?
Just a suggestion, not a mandate: maybe we should consider whether this argument can actually lead anywhere useful. I think there is agreement on the basic facts, and merely disagreement over characterization; no? -- David Abrahams BoostPro Computing http://boostpro.com
On Dec 6, 2009, at 8:33 PM, David Abrahams wrote:
On Dec 7, 2009, at 1:28 AM, David Bergman wrote:
So yes, there *is* overlap but it is certainly far from total, right?
Not far from, no. If you bring up one feature, multi-TU FSM, I would not call that "far". The overlap is 95%. No?
Just a suggestion, not a mandate: maybe we should consider whether this argument can actually lead anywhere useful. I think there is agreement on the basic facts, and merely disagreement over characterization; no?
No, there is not agreement about facts. I think that almost all features are common between the two and that the way to use those features are quite similar, and very similar for non-guarded, non-nested cases. This is in disagreement with what Andreas, for one, believes: that the overlap is far from total. Since I seem to be a singleton minority in my view, I am wrong (statistically speaking...) Why am I so anal about these matters this time, when complacently watching other proposals fly by - often in utter silence? Because - beside being a junkie for vertices and arrows in all shapes and forms - I think a second library solving the exact same problem as an existing one does require quite some scrutiny, and I also want to understand if this review comes down to mostly measuring differences in runtime characteristics. I would like to use one common interface and then switch engine dependent on runtime needs, or compiler limitations. That is what I did in my embryo to a common predecessor, diagrammatically speaking, treated in a recent post of mine. /David
On Dec 5, 2009, at 12:32 PM, Andreas Huber wrote:
Ignorant? Andreas, I can tell you one thing: I am anything but ignorant.
Ok, I'm listening. How well do you know Statechart? Have you read the tutorial? Have you read the rationale?
Well, another thing: the feature set is almost identical, and it is hard to tell to which library this description belongs: Features include: Straightforward transformation from UML statechart to executable C++ code and vice versa. Currently, this needs to be done manually both ways but it should not be difficult to automate these tasks Comprehensive UML semantics support: Hierarchical (composite, nested) states Orthogonal (concurrent) states Entry-, exit- and transition-actions Guards Shallow/deep history Event deferral Error handling support Maximum type-safety Compile-time statechart validation Support for asynchronous state machines and multi-threading State-local storage Generic design allowing for the customization of memory management, error handling and threading /David
Remove libraries? Current users of the to be removed library would be delighted to learn that their code will no longer compile with the next version of Boost. Deprecated libraries? Seems like a good idea, if the new library offers a strict superset of the features of the old one. In reality this will almost never happen.
Well, that is the case with Spirit 1 and Spirit 2, right?
Spirit 2 offers a strict superset of the Spirit 1 functionality, right? This is not the case with MSM and Statechart.
How do you think it feels for new Boost users to encounter two libraries with virtually identical use and interface?
The interface is very different and there's also difference in 2 key features (as I've pointed out in another post). -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
1. Is there a Boost library removal process, so that one can at least mark a library as >deprecated? The duality, sort of, to the acceptance process.
You deprecate code or functionalities to reduce maintenance costs. One example of a valid reason to deprecate a library in Boost would be when there is no maintainer for it. Another reason would be a library that has got a large number of unresolved issues. To completely remove a library from Boost, one could consider that a library that has been deprecated for a given period could be voted for removal. When you decide to have deprecation and removal in your maintenance process, it must be formal, objective and easy to understand. -- EA http://www.bureau14.fr/ __________ Information from ESET NOD32 Antivirus, version of virus signature database 4658 (20091203) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
AMDG David Bergman wrote:
I have two (harsh?) questions to this community:
1. Is there a Boost library removal process, so that one can at least mark a library as deprecated? The duality, sort of, to the acceptance process.
FWIW, one library has been removed from Boost. (But that's ancient history now) In Christ, Steven Watanabe
participants (17)
-
Andreas Huber -
Andrew Venikov -
Andrew Venikov
-
Christophe Henry -
Darryl Green -
Dave Abrahams -
David Abrahams -
David Bergman -
Edouard A. -
Jeffrey Bosboom -
Michael Caisse -
OvermindDL1 -
Patrick Horgan -
Phil Endecott -
Rob Riggs -
Robert Ramey -
Steven Watanabe