November 2009 - Boost - lists.boost.org

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 30 Nov '09

30 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