- Boost - lists.boost.org

[1.42.0] Release branch open for merges
by Beman Dawes 01 Dec '09

01 Dec '09

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging *does not* require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: http://svn.boost.org/trac/boost/wiki/ReleaseSchedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Release Managers, Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

3 3

[msm] Review
by Christophe Henry 01 Dec '09

01 Dec '09

Hi Juraj, First of all, thank you for being the first one to write a review. I imagine it's not an easy thing. Thank you also for bringing a few very interesting points to the discussion. I'm happy to build on them and hope to finally start some discussion. >MSM does lack some of the SC functionality. >There is no state-local storage in SC sense, as all states are >constructed when main state machine is constructed. This can be easily >worked around though. As this point is being brought for the second time, I'd like to spend some time on it. You already have state local storage with msm, just not like with SC. Like SC, msm defines states as classes, meaning they can have data. There is however one important difference with SC. Msm builds all the states upon state machine creation. States are not destroyed until state machine destruction. This has advantages and disadvantages: - states must be default-constructible - you might need to heap allocate the state data if you cannot initialize it at state construction. + speed: states don't need to be constructed again and again. Constructing a state (and its attributes) each time it becomes active can be costly, even if memory allocation can be optimized. + your state data is always available. In my experience, state data is not only needed in the entry or when the next event is processed, but during a transition or even at some time after a transition. This means, that you have, during a transition, access to data from the source or the target state. + combined with the visitor, you can at any time access data from the currently active state and build a generic way to do something with state data. + you can build examples like the iPodSearch where states keep iterators to some container, thus keeping information from an iteration to the next one. + you avoid having data released inside a destructor. Knowing that destructors should not throw, it makes your life easier. + on_entry is templatized, giving you more leeway to add event-specific handling. + your event data is not lost upon state entry Msm's handling is hard to emulate with SC, on the other hand, SC's handling is easy to emulate with Msm. It has its drawbacks but all considered, I think it is a superior solution. >It is impossible to stop event from propagation (SCs discard_event()) >without actually changing state. It is true. At the moment you cannot. Actually, I don't think UML foresees this possibility. OTOH, I think it is an interesting one and will be happy to borrow it from SC. I think that using the transition table is one of Msm's biggest strengths so I offer to add a row or a functor allowing event propagation to be stopped. You could even give it a guard, thus allowing fine-grained transition conflict resolution. > You cannot conditionally defer an event. Again you're right. I think UML doesn't foresee this either, but I also like it and will also borrow it from SC. You offered the idea of a d_row (deferred row) or dg_row (the same with a guard). I think it is the best possibility with the simplest front-end and makes deferred events a first-class citizen, being in the transition table and coming into play during conflict resolution. For the functor and eUML front-ends I think it could be done as an execution row. Something like: State1() + Event1() / defer_() Seems an interesting starting point. >There seem to be some differences on how event deferral is handled when > composite states are used. This part is a still bit mysterious to me. I will add a part about the dispatch algorithm to the documentation. >Aesthetically - I'm not a great fan of one big fat html documentation > and would prefer to have it broken down and cross-referenced as most > boost libraries docs are organized, but this is just a minor issue. If Msm is accepted into Boost, I'd probably move to BoostBook anyway, so this will be done at this time. > The author seems masochistic enough to try to tackle this. :) Sure :) and I don't mind the term at all :) Thanks for the review and the very good points you brought during the last weeks! Regards, Christophe

3 2

Re: [boost] [msm] Review
by Christophe Henry 30 Nov '09

30 Nov '09

Hi Sebastian, > I know nothing about MSM and very little about state machines in > general, but if all states are constructed at SM instantiation time, > would it be possible to pass the SM constructor a tuple of constructed > states that are copied/moved into the internal states? In theory it'd be possible because MSM stores the states in a fusion::set, which can be constructed from a forward sequence. And according to the fusion doc, a tuple can be adapted to a forward sequence. So I suppose it'd work. The problem would be to find an acceptable syntax because a msm::back::state_machine already has a templated constructor used to pass arguments to the front-end, for example: struct player_ : public msm::front::state_machine_def<player_> { player_(int some_value){…} } typedef msm::back::state_machine<player_ > player; player p(3); So we'd need to pass the tuple as extra argument, the first or the last one and add a bit of SFINAE to check if this argument is a tuple. > Would it be worth the effort? I don't know. It has never been requested so it's hard to know, but I find the idea quite interesting. Let's make a quick poll (which I'll shamelessly use as a way to make the review slightly more alive). Would someone make use of this feature? Christophe

1 0

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 30 Nov '09

30 Nov '09

> Why the transition table uses non-type template parameter for actions > and guards instead of using a agreed function name for handling events > in states? Thinking further about it, do you mean like Statechart's react function? It'd be possible of course, I even imagined adding a SC-like frontend. The problem is, when your fsm becomes bigger, you might find out that following what your fsm is doing is harder because you have to look in many different places in your code. On the opposite, having more information in the transition table will help you have a better view of the structure of your state machine when it gets bigger. The other drawback (in my opinion) of SC's react, is that it automatically forces on you some forward state declaration as a state will need to know all of its possible followers. It also prevents reuse of states or composites in another fsm. And finally, my biggest worry about such a react function is that it becomes harder to build a GUI which can generate your code from a diagram and next to impossible to parse back the code into a model, so it 's not an ideal approach for Model-Driven development. A transition table, on the other side, makes it pretty simple to build a tool whose job is model <-> code development (both ways). Regards, Christophe

1 0

[program_options] Formatting; split at space
by Chard 30 Nov '09

30 Nov '09

Function: format_paragraph File: options_description.cpp, line 423: if (last_space != line_begin) { // is last_space within the second half ot the // current line if ((unsigned)distance(last_space, line_end) < (line_length - indent) / 2) // "- indent" ? { line_end = last_space; } } I'm given to understand that the code around here is designed to split the description at a space, iff the space occurs at least half-way through the description text. The code currently subtracts the indent from the line_length, where the line_length (within format_paragraph) represents the space available for the description (indent has already been subtracted from line_length at the beginning of format_paragraph). The result is that the longer the option names, the less chance of the split occurring at a space within the description. Was this the intention? E.g. if an option is 40 chars long, then there is no chance of it splitting at a space (for 80 column default).

2 1

property_tree equal_range causes compiler error
by YuQian Zhou (周宇前) 30 Nov '09

30 Nov '09

add to boost/libs/property_tree/examples/debug_settings.cpp: line 55 pt.equal_range("debug.level"); then compile: ~/boost/libs/property_tree/examples$ g++ -I../../../ debug_settings.cpp -o debug_settings ../../../boost/property_tree/detail/ptree_implementation.hpp: In member function ‘std::pair<typename boost::property_tree::basic_ptree<Key, Data, KeyCompare>::assoc_iterator, typename boost::property_tree::basic_ptree<Key, Data, KeyCompare>::assoc_iterator> boost::property_tree::basic_ptree<Key, Data, KeyCompare>::equal_range(const Key&) [with Key = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Data = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, KeyCompare = std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]’: debug_settings.cpp:55: instantiated from here ../../../boost/property_tree/detail/ptree_implementation.hpp:449: error: ‘class boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > > > >’ has no member named ‘base’ ../../../boost/property_tree/detail/ptree_implementation.hpp:449: error: ‘class boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > > > >’ has no member named ‘base’

2 1

Can someone with Visual Studio take a look at bug #1076, please?
by Marshall Clow 30 Nov '09

30 Nov '09

There is a test case attached to the bug: https://svn.boost.org/trac/boost/ticket/1076 Thanks! -- Marshall

3 3

Status of the bug sprint....
by Marshall Clow 30 Nov '09

30 Nov '09

for Thursday, November 19th. Yesterday, 859 open tickets. Today, 861 open tickets. That's not the direction that we want to go, folks. ;-) -- Marshall

7 26

Compiler Warnings Tests
by Paul A. Bristow 30 Nov '09

30 Nov '09

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] > On Behalf Of Robert Ramey > Sent: Friday, November 27, 2009 5:07 PM > To: boost-users(a)lists.boost.org > Cc: boost(a)lists.boost.org > Subject: Re: [Boost-users] Compiler warnings from Macs, IBM acc, Borland, Comeau, > Metroworks, et al - are they a Problem? > > I know this suggestion has been made but I want to expand a little on it. > > a "library" - warning policy test. This would be just like any other > library as far as the testing system goes. It would have maybe > 10? small compile only tests which would emit warnings or not. > The source would describe which warning is in fact being tested. > > Presumably, the test matrix would permit one to look at the warning > messages. (I'm not sure that the current one does this). > > In anycase, it would permit the test matrix be used to check > the warning status for each warning on each compiler at > a specified warning level. > > I see this as the only way to get a real grip on how these things > vary among the array of compiler's we might use. > > I realize that it would be some work, but I would think it wouldn't > be all that much more - if any - than that which has already been > expended on the wiki. It would have the great advantage of > being relatively free of "maintainence by hand". It would automate > the whole process of determining the status of different compilers > in this area. OK I can see some merit in this (now I understand your proposal a bit more). And I'm starting a new thread for Compiler Warnings Tests The Microsoft docs examples might be a good start? // C4244_level4.cpp // compile with: /W4 == actually warnings = all (warnings = errors will allow normal fail testing if it isn;t possible to check for warnings?) // AND MS extensions off? int aa; unsigned short bb; int main() { int b = 0, c = 0; short a = b + c; // C4244 bb += c; // C4244 bb = bb + c; // C4244 bb += static_cast<unsigned short>(aa); // C4244 bb = bb + static_cast<unsigned short>(aa); // OK } So are you proposing a collection of these, with versions that should compile and others that should not, for example: int main() { int b = 0, c = 0; short a = b + c; // C4244 } and another with int main() { int b = 0, c = 0; short a = static_cast<short>(b + c); // OK - NO C4244 } all run by a jamfile.v2. Or am I still misunderstanding you? Vicente has said he will think about it. I will also give it some more thought. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

4 7

[buiild] stop on first error
by Vladimir Prus 30 Nov '09

30 Nov '09

As of today, if you run: ./bootstrap.sh ./bjam in trunk, then the build will immediately stop on any error. The same is true with bootstrap.bat on Windows. The previously behaviour was to continue building other targets that don't depend on the failed one. The "keep going" behaviour has some good properties, for experienced users, but for new users of Boost, it was sufficiently confusing: - It's easy to miss compilation error, and then you learn that something has failed at the end of build - There's no clean at-the-end summary of what has failed, and what to do - Some users don't even know how to capture build output for further analysis, and the build output, with all the errors, can easily overflow scrollback buffers of console windows The new behaviour is implemented by writing an option into project-config.jam. Anybody who wants the old behaviour can edit that file, or pass --keep-going on the command line. The change does not affect regression tests. - Volodya

3 3