- Boost - lists.preview.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

[filesystem][iostreams][program_options] linker issues on msvc
by Alexander Arhipenko 30 Nov '09

30 Nov '09

Guys, We use boost.build not only for building boost but also to create own binary packages. For a long time I observe linker errors on msvc due to lack of usage requirements in Jamfile's. Issue is reproduced when somebody builds executable like this: exe foo : main.cpp /boost/filesystem ; #or /boost/program_options or /boost/iostreams Following trivial patch resolves these issues: Index: libs/program_options/build/Jamfile.v2 =================================================================== --- libs/program_options/build/Jamfile.v2 (revision 57802) +++ libs/program_options/build/Jamfile.v2 (working copy) @@ -1,6 +1,9 @@ project boost/program_options : + usage-requirements + <link>shared:<define>BOOST_PROGRAM_OPTIONS_DYN_LINK=1 + : source-location ../src ; @@ -17,4 +20,4 @@ <link>shared:<define>BOOST_PROGRAM_OPTIONS_DYN_LINK=1 # tell source we're building dll's ; Index: libs/filesystem/build/Jamfile.v2 =================================================================== --- libs/filesystem/build/Jamfile.v2 (revision 57802) +++ libs/filesystem/build/Jamfile.v2 (working copy) @@ -11,6 +11,7 @@ project boost/filesystem : source-location ../src : usage-requirements # pass these requirement to dependents (i.e. users) + <library>/boost/system <link>shared:<define>BOOST_FILESYSTEM_DYN_LINK=1 <link>static:<define>BOOST_FILESYSTEM_STATIC_LINK=1 ; @@ -29,4 +30,4 @@ : ; Index: libs/iostreams/build/Jamfile.v2 =================================================================== --- libs/iostreams/build/Jamfile.v2 (revision 57802) +++ libs/iostreams/build/Jamfile.v2 (working copy) @@ -7,7 +7,11 @@ # See http://www.boost.org/libs/iostreams for documentation. -project /boost/iostreams : source-location ../src ; +project /boost/iostreams + : usage-requirements + <link>shared:<define>BOOST_IOSTREAMS_DYN_LINK=1 + : source-location ../src + ; # The biggest trick in this Jamfile is to link to zlib and bzip2 when # needed. To configure that, a number of variables are used, which must Regards

3 9

Crazy Borland/Codegear long long behaviour?
by John Maddock 30 Nov '09

30 Nov '09

I'm having a load of trouble getting Boost.Integer to play nice with the Borland/Codegear compilers, for example given: void print_val(long long l) { std::cout << std::hex << static_cast<int>((l & 0xFFFFFFFF00000000LL) >> 32); std::cout << std::hex << static_cast<int>((l & 0xFFFFFFFFLL)) << std::endl; } And then: static const long long MaxValue = SCHAR_MAX; static const long long sll = _LLONG_MAX; const long long cll = _LLONG_MAX; long long ll = _LLONG_MAX; BOOST_TEST(MaxValue <= ::boost::integer_traits<boost::long_long_type>::const_max); // fails BOOST_TEST(MaxValue <= _LLONG_MAX); // passes BOOST_TEST(MaxValue <= sll); //fails BOOST_TEST(MaxValue <= cll); // fails BOOST_TEST(MaxValue <= ll); // passes print_val(_LLONG_MAX); // OK prints 7fffffffffffffff print_val(ll); // OK prints 7fffffffffffffff print_val(sll); // Oh no, prints ffffffffffffffff print_val(cll); // Oh no, prints ffffffffffffffff So as soon as a long long is declared const (whether static or not) it seems to be incapable of actually holding a sensible value!! Anyone got any ideas what's going on or any workarounds? Thanks, John. PS I'm still using Borland-5.8.2, but judging by the test matrix results the latest versions have similar issues.

3 4

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

29 Nov '09

Hi Felipe, > 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? I'm not sure I understand the question. Please excuse (and correct) me if I miss the point. You mean, why not remove action and guards from the transition table and delegate all handling to a state (source or target)? Well, you can do this if you want, as there are already such methods defined, on_entry and on_exit. So theoretically you could use a _row, which has only source state / event / target state and delegate all work to on_entry and on_exit. It would work in some cases. However, you could also have the following: _row< State1, event1, State3>, _row< State2, event2, State3> and maybe _row< State1, event3, State4> Now you have a problem in State1 and 3. State3 can be the target of 2 transitions from 2 states and State1 can be the source of 2 transitions to 2 states. Where to add the common handling? It'll fatally end with some if/else on the event type. If you carefully choose your on_entry/exit, action and guard you will avoid this and get cleaner code with on_entry and on_exit (called each time a state is entered/left independently of the event) doing the work common to all transitions and the action/guard the work specific to one event. To be honest, as on_entry and on_exit are templatized on the event you could use SFINAE to handle event-specific tasks and get rid of actions and guards anyway but SFINAE isn't everybody's tool. If you feel good with them, then sure, why not? > That should get the transition table a lot smaller and maybe even > faster for not using a pointer (though speed-wise, that's a wild > guess). Luckily Msm allows you both ways :) You have a valid point with your wild guess. I'm unsure myself why but if you use the functor-based frontend, which is doing strictly the same, you will see some speed gain (about 20%) compared to the pointer version. I hope I could answer the question satisfactorily. Regards, Christophe

1 0

[config] BOOST_CONSTEXPR and C++0x constexpr
by Vicente Botet Escriba 29 Nov '09

29 Nov '09

Hi, I was wondering if it will be useful to define BOOST_CONSTEXPR as follows #if defined(BOOST_NO_CONSTEXPR) #define BOOST_CONSTEXPR #else #define BOOST_CONSTEXPR constexpr #endif and if it is correct to use it as for example static BOOST_CONSTEXPR Rep zero(); If this is the case, could this be added to Boost.Config? If not, what I'm missing? Best, Vicente -- View this message in context: http://old.nabble.com/-config--BOOST_CONSTEXPR-and-C%2B%2B0x-constexpr-tp26… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

GGL Review Results
by Hartmut Kaiser 29 Nov '09

29 Nov '09

Hi all, The review of the Generic Geometry Library is over now. We have had vibrant discussions with regards to the library itself. In addition those stirred up a lot of controversial discussion about the Boosts review process. In this review results I will concentrate on the library at hands. Formally this review ended with 12 YES and 2 NO votes. This result reflects the overall discussion and the general consensus of this library being worth to be included into Boost. Based on this result and the discussions the Generic geometry Library has been formally accepted into Boost. It is worth highlighting that most of the reviewers emphasized the excellent quality of the library design. Here are some quotes: - "The design is very clear. I think it can serve as a standard example of how to cover a big non trivial problem domain using meta-programming, partial specialization and tag dispatch to make it uniformly accessible by a set of generic algorithms." - "The design looks clear enough so that I was able to understand about what was being done. Adding concept checking is a good idea. It also surely is a modern generic design." - "I am quite pleased with the use of tag-dispatching and strategies. I was happy to see this approach taken and by looking at the documentation and source code it seems sound. I believe this approach offers the greatest latitude for a generic library." At the same time the 2 NO votes reflect a couple of shortcomings which still need to be addressed before final inclusion into SVN. Here is a list of contingencies noted by the reviewers: - Robustness: algorithmic robustness and arithmetic stability have been discussed widely. The consensus of the reviewers is that all algorithms need to be robust and that the user should be able to make sure all calculations are arithmetically stable. GGL addresses arithmetic stability by allowing to instantiate all algorithms with arbitrary number types. But it turns out not the entire library has been converted to use this scheme yet. Any design issues that would prevent strong robustness guarantees (without drastic refactoring) in the future should be identified and fixed prior to release. The documentation needs to reflect the actual guarantees and complexities of every algorithm. - Concepts: more refinement needs to be done for the existing concepts. At least 2 users claimed to not have been able to adapt their data structures to the existing scheme. The library aims for defining the concepts and interfaces for future geometry related work in Boost, so these use cases need to be addressed. Users mentioned the missing concept inheritance. This might be a good way to address the current problems of concepts being too fine grained and too difficult to use. What needs to be done at minimum is to enhance the flexibility of the concept mechanism enabling to adapt user provided data structures more easily. The concepts need to be sound even in the light of extensions. - Boolean operations: while the library provides a set of Boolean operations those seem to be not complete and/or robust in terms of clockwise/counterclockwise geometries, closed/open polygons. Robust Boolean operations are a strong requirement, so this should be fixed as reported by at least one reviewer. - Documentation: the documentation of the library is not complete and needs additional effort. Using Doxygen alone as a documentation tool has its (known) shortcomings when it comes to generic libraries. The authors already mentioned to plan to switch to QuickBook after review allowing to have better control over the generated docs. - Testing: several reviewers mentioned the need for a thorough testing framework allowing the verification of the correctness of the algorithms in a wide range of use cases. Different test strategies need to be employed, such as high volume and random tests, known border case tests, tests using different numeric precision types, etc. Minor (non-contingency) issues: - Names of used concepts: currently the library is using mainly terms as established by the OpenGIS Consortium (OGC). This is misleading for users coming from different (non-GIS) domains. It has been suggested to introduce different namespaces for the different geometry domains (GIS, graphics, 3D, etc.) allowing to use the expected terminology established in that particular domain. - Name of the library: the name 'GGL - Generic Geometry Library' is misleading as it is not a generic geometry library but a library using generic programming techniques related to geometry. It has been suggested to use the name Boost.Geometry instead. This is not a requirement imposed by the review results, but I would like to suggest to the authors to consider renaming. - Integration with Boost.Units has been suggested. The library does not need to be completetly integrated with Boost.Units, although it appears to be reasonable to deal with types as exposed by Boost.Units especially for distance and area calculations. - Spatial data structures (such as spatial trees) have been mentioned to be crucial for a geometry related library. While the library can't implement all possible data structures in this field it can (and should) define concepts and interfaces allowing future extensions while maintaining interoperability. - In addition to that the reviewers made a lot of remarks related to different smaller inconsistencies part of which already have been addressed during the review. Barend has a full list of the remaining ones and promised to address all of them. Last but not least I would like to encourage cooperation between the authors of this library and the author of Boost.Polygon as both libraries have their strength' worth combining. In an ideal world and at some point I would like to see both libraries to be merged. But this is obviously not something to expect really soon. At this point I would like to thank all who participated in the review and, certainly, the authors for submitting this excellent library to Boost. Regards Hartmut GGL Review Manager ------------------- Meet me at BoostCon http://boostcon.com

2 1

Boost.Integer makeover
by John Maddock 29 Nov '09

29 Nov '09

Folks, Boost.Integer has had a quick makeover in Trunk - starting from the "last known good" release - and then fixing all outstanding issues filed since that release. New-look docs are visible here: https://svn.boost.org/svn/boost/trunk/libs/integer/doc/html/index.html I'd really appreciate it if: * Folks can read through the docs looking for the usual SNAFU's * Test the code on whatever exotic compilers/platforms you may have available. Some random thoughts that occurred to me while doing this: * I don't see the point of the static-min-max templates - there are 4 of them when 1 would probably do (template <class T, T val1, T val2> static_min_max), but in any case the implementation is almost too trivial for a separate template to make sense? * I haven't added mpl-compatible templates yet as per https://svn.boost.org/trac/boost/ticket/1224, is there demand for this? Cheers, John.

9 22

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

29 Nov '09

Hi Darryl, > I found code size of stripped executables compiled with gcc 4.3 to be > quite reasonable - especially at high optimisation levels, although > still about twice the size (the docs state) VC9 achieves. I'm assuming > that the large sizes mentioned are simply due to the generated files not > being stripped. Correct. Stripping will greatly improve the executable size, eventhough it'll still be more than what VC produces. > I was unable to compile the euml example - I haven't investigated the > errors yet. g++4.3 should manage this. Please contact me if you need any assistance. > I had hoped to pick what I'd consider a realistic use for a high > performance FSM tool (a low level comms protocol) and do a basic mock-up > implementation using MSM. However a reasonably typical layer 2 protocol > (LAPD) has 8 states and a transition table that in a condensed form (row > for each event, column for each state with the column describing the > actions and transition) is 10 pages long, so it is pretty obvious I > can't do that... Its likely that a bit of refactoring could bring the > total number of transitions down somewhat using composite states, but > the number of events to be handled exceeds the typical limits for number > of transitions so this still seems hopeless. 8 states doesn't seem like a huge number to me. How many transitions are we talking about? I'm not so sure that it can't be done, especially as you're using g++ 4.3 which is the best compiler with Msm. I managed to compile 100 transitions in about 40s (while running in a VM). I'm pretty sure the compiler can manage more. Supposing that every of your 8 states has a distinct transition to every other state including itself it'd be 64 transitions, which your g++4.3 will easily manage. You can even allow yourself to have more than one to every state. In the very worst case, if you had so many events (say more than 100) that g++4.3 itself would crash we could easily group events with the same source and same transition inside the same event and reduce the number of transitions to what g++ would manage. > At this point, I really like what msm is trying to do - it just doesn't > quite do it for me in a practical application. Maybe that just means > waiting for Moore's law and compiler technology to catch up? Well, it'd be a solution but hopefully we won't have to wait yet ;-) Seriously, I'd be happy to work with you on this one. It'd be quite fun and I'm pretty confident it can be done if I'm right about my assumption on the number of transitions. Regards, Christophe

2 1

First results using Comeau C/C++ compiler
by Mateusz Loskot 28 Nov '09

28 Nov '09

Hi, After quite some time of trying to build Boost, especially Boost.Test, using Comeau C/C++ frontend with GCC 4.x on Linux, I've started to get some promising results. During this investigation I was juggling number of fixes and patches [1] and eventually I found quite surprising solution. Yesterday, while reading signal.h and other headers to find out how to get signals features compiling for Boost.Test library, I came across an interesting macro which seems to be a passkey to the world of GNU C Library for Comeau toolset :-) It is _GNU_SOURCE macro [2]: "If you define this macro, everything is included: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, LFS, and GNU extensions." Defining this macro seems to solve all issues I reported [1] so far. BTW, I've sent request to Comeau team for their opinion about usage of this macro with Comeau C/C++ frontend. Hopefully, it will be assumed safe to use, then we've got solution for all/most of the problems. Second due to the fact Comeau does not support linking as shared, I had to explicitly request to link Boost.Test binaries statically. I attach patch for Boost.Test Jamfile.v2 files adding the macro and configuring static link for como toolset. Let it be an example showing what kind of changes/options are needed by como toolset to build Boost.Test binaries. I haven't tried, but I suppose it's safe to assume that the same changes are needed to build other libraries like Asio, Program Options, and others. I'm going to find it out. To summary, there are two required changes in build configuration to enable como toolset, so far. So, what is the best approach to incorporate those two settings to other libraries (only those when it's needed): * Should I hack all Jamfiles where those changes are needed? * Or, it would make sense to set these options for como toolset, by default? * Where <link>static should go? To Jamfiles or nowhere and static linking should be explicitly enabled as bjam argument? I also tested: como --v2 link=satic Gennadiy, I'm sorry for making quite a mess in Trac by reporting number of tickets and submitting number of patches which eventually turned out to be unnecessary. It took me number of iterations to sort it out and I was subsequently recording my discoveries. [1] - int64_t/uint64_t https://svn.boost.org/trac/boost/ticket/3548 - snprintf, vsnprintf https://svn.boost.org/trac/boost/ticket/3558 - POSIX features (e.g. signals.h) https://svn.boost.org/trac/boost/ticket/3662 [2] _GNU_SOURCE http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

3 4

[flyweight][#3658] Dependency on static initialization/destruction order
by Andrey Semashev 28 Nov '09

28 Nov '09

Hi, I've created the ticket #3658 [1] on the flyweights library. The ticket is about Boost.Flyweight depending on the static initialization/destruction order, which can lead to application crashes in some cases. The library does provide certain tools to work around the problem [2], but these tools are only usable in the most obvious cases and do not solve the problem in its root. What I have proposed in the ticket is to implement reference counting in the flyweights, so that the flyweight value is only destroyed when no flyweight handles refer to it. AFAIK, Boost.Flyweight already has reference counting, so the work is only to shift value owning from the holder to the flyweights. Comments are welcome. [1] https://svn.boost.org/trac/boost/ticket/3658 [2] http://www.boost.org/libs/flyweight/doc/tutorial/technical.html#static_init

2 2

[msm] Review
by Juraj Ivančić 28 Nov '09

28 Nov '09

Hi all, This is my first attempt at reviewing a library, so please bear with me. - What is your evaluation of the design? I think that MSM is brilliantly designed and offers a great deal of advantages over StateChart (SC). The part I like the most about MSM compared to StateChart is the way state machine is defined. Transitions are not a part of state, but are listed in the state machine itself in the transition table. Although it is generally a bit more difficult to write the MSM transition table than its SC counterpart (especially when resolving transition conflicts) I found it very rewarding. It gets difficult to get a clear picture of SC state machine when it gets large - especially when many custom_reactions are used. Also, when composites are used in SC, it is difficult to figure out the hierarchy. IOW SCs distributed sm definition makes it very hard to get a clear picture of what is going on without a pen and paper at hand. Please do not think that I have anything against SC - I have been using it since it became a part of boost and still intend to. It has saved me from writing my own feeble double-dispatch implementations and saved me a lot of time and nerves on more than one occasion :) 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. It is impossible to stop event from propagation (SCs discard_event()) without actually changing state. You cannot conditionally defer an event. 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. A MSM feature I really like though is that on transitions both source and target state exist. This allows storing transition event data in the target state in case this is needed. This could not be done in SC because on target state construction event that caused the transition is lost. The latest MSM 2.0 offers separation to front-end/back-end. This is potentially a very powerful feature which makes me hope that some day in the (nearby) future I'll be able to create/modify a state machine in some GUI app and have it automagically transformed into high performance C++. The author seems masochistic enough to try to tackle this. :) - What is your evaluation of the implementation? Reading the implementation quickly causes a severe headache. - What is your evaluation of the documentation? It found it well written and containing useful examples. The first part is pretty much quick-start guide, and it gets more and more complicated as you read along. I found it lacking info on some border-line cases. It does however often reference UML state machine standard, which I am unfamiliar with, so this could be my fault. 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. - What is your evaluation of the potential usefulness of the library? I find it very useful in its current state. Furthermore, I gathered that the author is planning on adding new front-ends (back-ends?) thus making it even more so. - Did you try to use the library? With what compiler? Yes, with MSVC9. - Did you have any problems? As it often is with metaprogramming libraries, error messages leave much to be desired. I had to figure out how to use mpl::vectorX with X>50. This ancient post helped: http://tinyurl.com/yf7e9mo It wouldn't hurt to have it included in some way in the docs. There are some behind-the-scenes vector unions in MSM, so it is possible that you will require, e.g. mpl::vector60 without ever directly using mpl::vector with more than 40 members. The exact formula for determining max needed vector size would be useful. MSM state machines compile for ages. I also managed to find a bug or two and some documentation errors. I sent reports to the author and he had them resolved in literally hours. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? As in-depth one can get without looking under the hood. Thorough read of the docs, playing around/testing and nagging the author :) - Are you knowledgeable about the problem domain? Not especially. I spent a great deal of time using StateChart and have played with the MSM 2.0 for the last couple of weeks (since the announcement on this list). I have also recently ported a pretty complex state machine (~15 states, ~80 transitions) from SC to MSM. And finally, yes, I think that this library should be accepted as a part of boost.

1 0

Interest in Devector implementation?
by christopher hopman 28 Nov '09

28 Nov '09

So, I have been working on a devector implementation for the last week or so (see https://svn.boost.org/trac/boost/wiki/soc2009#Boost.Devector) There is some stuff that still needs to be done, and some testing that is still needed, but I thought I would check if there was interest in such a thing. The implementation is basically a standard deque implementation with one addition. That is, there can be allocated "chunks" both before and after those in use. This leads to a couple of advantages for users. First, in many use cases, devector is faster than deque because it will have less allocations. For example, when used strictly as a queue, the regular deque has a number of chunk allocations linear in the total number of elements inserted in the queue, devector has allocation linear in the maximum elements in the deque at one time. When used as a stack, a particularly bad case can occur with a normal deque implementation, the case where the top of the stack switches back and forth between two chunks. Second, this allows users of devector to reserve space on either side of the structure. This does not give the same efficiency boost as vector::reserve, but, possibly more important, it allows for stronger exception guarantees and for better guarantees about when iterators are invalidated. Another benefit of devector is that chunk size is not a compile time constant. In fact, chunk size is not even required to be constant over the lifetime of a given devector. Also, devector iterators allow lower level access than std::deque as described by Matt Austern ( http://lafstern.org/matt/segmented.pdf) Support for in-place construction (described at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2212.html) will become available with c++0x's emplace_back(). Though I expected that std::deque would have a slight performance advantage due to its compile-time constant chunk_size, early tests have actually shown devector to have a slight advantage even in cases where it has no advantage from not deallocating unused blocks. My guess is that this is due to std::deque needing to do more work to maintain its invariants in the face of exceptions. Again though, that is just some simple early testing that I did. The current implementation does not actually allow changing chunk_size (though this is actually a matter of like 5 LOC), nor does it give the segmented iterator access (again a simple addition). Code is available at http://pages.cs.wisc.edu/~hopman/devector/ (along with code that tests most of the std::deque interface). -Chris Hopman

1 0

[serialization] polymorphic archives + boost_class_export generates linker errors
by Christoph Heindl 28 Nov '09

28 Nov '09

Hi, I've posted this with no luck to the boost-users mailing list: the attached example [1] generates a couple of linker [2] errors on msvc 9.0 / boost 1.40.0 all related to missing archive_serializer_map symbols. when switching from polymorphic archives to corresponding non-polymorphic archives the attached example runs fine. It seems that the usage of BOOST_CLASS_EXPORT in conjunction with polymorphic archives triggers the linker error. I tried to add explicit template instantiations, such as [3], for the missing types to boost archive, recompiled boost and was able to get rid of the linker error. The problem then, however, is that the example fails at runtime with an assertion that a type-lookup did not succeed. So I guess adding the explicit template instantiations was not the correct approach. Is this a bug? Can anyone confirm this issue? Best regards, Christoph

4 10

[random] documentation rewrite
by Steven Watanabe 28 Nov '09

28 Nov '09

AMDG I'm in the process of updating the Boost.Random documentation. I've put what I have right now at: http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/ The content is mostly the same as the current docs, although I've filled in some missing pieces and fixed some of the more egregious out of date docs. Any comments, criticism, etc, are welcome. In Christ, Steven Watanabe

5 10

Re: [boost] Boost.Array Maintainer
by raindog＠macrohmasheen.com 27 Nov '09

27 Nov '09

*top post* I think that it should be acceptable for other people to have the authority to submit patches and have them reviewed by other people and as long as they submit high quality code there should be the expectation that the code gets merged by someone who has the rights to do so. Look at other open source projects for ideas *end too post* ------Original Message------ From: Vicente Botet Escriba Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Subject: Re: [boost] Boost.Array Maintainer Sent: Nov 27, 2009 7:58 AM John Maddock wrote: > >>> Question: does someone have to be a maintainer of an existing library >>> (or author of one of the accepted libraries) to become a maintainer of >>> an existing (orphaned?) library? >> >> This is a very interesting question. Some lingering tickets with patch >> could be cleared faster if soem orphaned components of bosot were >> assignated new manager. > > Indeed. Something that occurred to me earlier was "how many tickets were > looked at in the last sprint, assigned a patch, but haven't been looked at > since?" That would be a good test of the owner being missing-in-action! > > Re Boost.Array, I seem to remember Alisdair Meredith taking this on, I'm > cc'ing him just in case my memory isn't what it once was ! ;-) > > It seems to me though that the bug sprints would be a good opportunity to > widen the maintainer list a little - what if we assigned an interested > volunteer to act as temporary maintainer for an orphan library during the > sprint. (S)he fixes whatever they can fix, then gets another bug sprint > volunteer to review the changes, if all looks well, and the tests are all > passing on Trunk, only then merge to release. > > Thoughts? John. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > Hi, I don't know if this is the best way, but it is clear that we have a problem with very old tickets. It will be great to identify the libraries that will need this kind of help, and make a call for volunteers. Best, Vicente -- View this message in context: http://old.nabble.com/Boost.Array-Maintainer-tp26534655p26544289.html Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

1 0

warning policy issue
by Robert Ramey 27 Nov '09

27 Nov '09

On page https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines#warn… it's suggested that the following warning at level 4 can be eliminated with a static cast warning C4244: 'argument' : conversion from <type1> to <type2> possible loss of data I've found this not to be true at least with msvc 7.1 Robert Ramey

5 9