- Boost - lists.preview.boost.org

Review Request: boost.lockfree
by Tim Blechmann 14 Dec '09

14 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi all, since my first review request for boost.lockfree [1] was completely ignored, here a second version for review. the main differences are bug fixes provided by various people, trying to run boost.lockfree on different compilers/platforms. the original review request was: i would like to submit a small library of lock-free data structures for review. boost.lockfree provides implementations of lock-free data structures. lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. boost.lockfree provides: * boost::lockfree::fifo, a lock-free fifo queue * boost::lockfree::stack, a lock-free stack updated links: the code is available from the boost vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost_… and from my personal git repository: git://tim.klingt.org/boost_lockfree.git http://tim.klingt.org/git?p=boost_lockfree.git the documentation is available at: http://tim.klingt.org/boost_lockfree/ would be nice if someone could add this library to the review schedule or even would be willing to manage a review ... best, tim [1] http://article.gmane.org/gmane.comp.lib.boost.devel/192779 - -- tim(a)klingt.org http://tim.klingt.org Avoid the world, it's just a lot of dust and drag and means nothing in the end. Jack Kerouac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAksLtukACgkQdL+4qsZfVssO7wCfel+ro8wr9TXA5fCHdq3+Dv0z 47sAniqHVyaQ4m4vOwr1SyRp9liUr9Dh =FZao -----END PGP SIGNATURE-----

12 18

Performance problem with boost thread
by ellan 14 Dec '09

14 Dec '09

My code is in C++; I am using thread_group directly. The thread group call a function member of the same class. In side this function member I called another class's function member to finish the task. The task is completely "embarrassingly parallel", thus I expect it scale very well. But it didn't, the performance of my code I describe above is even worse than when I use boost thread to call a executable instead of the function member of the same class. I don't understand what's going on. Any suggestions are really appreciated!!! -- View this message in context: http://old.nabble.com/Performance-problem-with-boost-thread-tp26779904p2677… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] [MSM] Comparison with ad-hoc FSM implementation
by Christophe Henry 14 Dec '09

14 Dec '09

>One interesting feature is that there are several buttons that have >different actions associated with short and long presses. So I can >imagine per-button state machines that do something like: > > UP --pressed--> DOWN --timeout--> LONG_DOWN > <--released---- | > <---------------------released--------+ > >These could feed events like left_button_short_press, >right_button_long_release etc into a main state machine. > >Can you outline how you would implement this in MSM? I implemented it exactly as you described. >I can see how you >could store the button identifier as event state and send e.g. >short_press(left_button) to the main state machine, but this would then >need transition rules using guards to test the button id. (I don't >think this is an application for a sub state machine because each >button's machine runs concurrently, right?) To make the follwowing answer clear, I just added in the sandbox (msm/libs/msm/doc) a BoostCon09 subdirectory. You will find the diagrams (top fsm, menu and playing submachines) and an implementation using a standard front-end and for the fun, another one using eUML (tested with VC9 and g++-4.3). I didn't generalize like you suggested. Though I like your solution and it is probably going to work, I didn't want to make the example more complicated (it is already complicated enough). To solve the concurrency problems, I simply added more regions and each button is handled in one of them. It is not such a big repetition because the south button has its own handling anyway. The interesting and complex part is not so much the button handling, which could be done with an ad-hoc solution too, but the separation of tasks between the regions. One handles the hold button and stops all processing using an interrupt state, some handle the buttons, and others are simply here to give to an hardware event (like using the middle button) a different meaning according to the state where the state machine is. For example, CheckMiddleButton is doing just this. Only one state. All regions are small, and each handles a very specific part of the problem. See it as a sort of "divide and conquer" ;-) The whole point of the example was to show how, using UML techniques supported by MSM, writing a mock-up for an iPod was easier than using an ad-hoc solution. We spent 90mn purely on diagram and used a tool to generate the code instantly. And this was the second point, to show how MSM was supporting a model-based approach and that such a tool was feasible. Christophe

2 1

[svn] merge to release HOWTO?
by Eric Niebler 14 Dec '09

14 Dec '09

I clearly am doing something wrong when it comes to merging changes from trunk to release. I feel that as one of the release managers, this is something I should know. :-P Long ago, the agreed procedure was to use svnmerge.py to merge individual revisions (or revision ranges) from trunk to release, running it from the root of the release branch. I have been faithfully doing it this way. But look at the result of my most recent merge: https://svn.boost.org/trac/boost/changeset/58336 The revisions I merged had only changes to proto and xpressive, but what actually got merged includes property changes to files and directories all over the map. What's going on? Am I not doing it the right way? -- Eric Niebler BoostPro Computing http://www.boostpro.com

6 7

Re: [boost] [msm] Review
by Christophe Henry 14 Dec '09

14 Dec '09

Hi David, Hi Darryl, >It is simply great EXCEPT for lack of instructions on how to actually leverage the design decision >to separate front and back end fully, i.e., helping me to define my OWN front end or back end for MSM. >So, I must take the design claim of separability with a tiny grain of salt. I didn't dream that someone would really ask me this :) Ok then I'll document this part. The interface between front- and back-end is pretty simple. Should you need any extension of it, please let me know, I'm very interested in your idea. > Yes, yes, yes! thanks :) >The name Meta State Machine is misleading. An FSM acting on other FSMs? >Or, to add the C++ modern (and in my view quite improper...) semantics of 'meta': an FSM being executed in compile-time? Nah. Short before the 1.0, there was only one class, state_machine (now the backend). So, like a metalanguage, which is a language used to build other languages, MSM was a state_machine to build state machines. Granted, afterwards, the pun looks less funny ;-) >I agree - how about ffsm - fast finite state machine - or should that be >frightfully fast state machine :-) Sounds cool :)

1 0

Re: [boost] [msm] eUML guard/action location
by Christophe Henry 14 Dec '09

14 Dec '09

>Yes it is an interesting "hack".How "pretend" have you been able to make >this? > >I was actually thinking about exactly this today (long drive - actually >- correction - I was thinking about it yesterday - it's now early >morning here) and wondering what the consequences were. Does it result >in actually default constructing all these (temporary) objects? Won't >that be expensive and/or have undesirable side effects? This is actually what I find so cool with the typeof feature (is it too late to donate a kidney for it? ;-) ). We are calling constructors and lots of operators and it costs nothing run-time because typeof only evaluate the return value of build_stt(...). So no call actually happens. All what you have really is a typedef. The only side effect (besides compiler support) is that you need an empty constructor or would be forced to pass some dummy value.

1 0

[rdb] 0.2.02
by Jean-Louis Leroy 14 Dec '09

14 Dec '09

I have uploaded a new release to the vault. It contains : * support for the float type. Internals have been cleaned up to make it easier to add new types * SQLGetData is not used anymore, result_set uses bound variables to read results I am a bit concerned about compilation time. Guess I'll have to take a look at the template profiler as well. I use float_ (note: underscore) for the variable type for receiving float values (and the length/null indicator). I am a bit tempted to switch to a convention that would prevent clashes with C++ names, e.g. Float or FLOAT. This would solve the problem of `select` clashing with the socket function from the C lib, e.g. : SELECT(p.id, p.name).FROM(p) ... Opinions on this ? Jean-Louis

6 9

[msm] Review
by David Bergman 14 Dec '09

14 Dec '09

Ugh, I have not had time to deal with MSM the last week, which is why I now have to quite hastily report my take on this library. An upside of this haste is that it will reduce my blabbering, which has already irritated a few people in this thread :-) First of all, and probably not a big surprise to anyone having followed this thread: there is already an FSM library in Boost, which has covered my needs in two projects, and quite possibly my needs in most applications. And, in order for me to want to include MSM, it needs to be significantly better, in terms of use (interface) or performance. Alright, let me get straight to the recommended bullet points for a review: - What is your evaluation of the design? It is very good. It actually gives me the same vibes that Boost.Graph does. And those are great vibes. They share part of the meta-programming style (using Boost.MPL) of Statechart, but does so in a better way. There are two important great design decisions: 1. Not coupling FSM logic to the individual states but to the machine itself. This is manifested by the separated transition table or eUML equations. This is conceptually aligned with the mathematical notions of FSM's. 2. The separation between front and back end, enabling multiple API's (of how to define the transitions); this latter point is also used by the eUML interface, which differs widely from the old one (in previous versions of FSM) and that of Statechart. In fact, eUML definitely warrants MSM the label "Xpressive for FSMs" - What is your evaluation of the implementation? Well, two things: 1. It has not crashed ;-) 2. It is very fast. In fact, with most of my examples, using non-nested but guarded machines, with less than 80 transitions, it is around six times faster than Statechart. - What is your evaluation of the documentation? It is simply great EXCEPT for lack of instructions on how to actually leverage the design decision to separate front and back end fully, i.e., helping me to define my OWN front end or back end for MSM. So, I must take the design claim of separability with a tiny grain of salt. - What is your evaluation of the potential usefulness of the library? Great - Did you try to use the library? Yes - With what compiler? Unfortunately only with (Apple's) GCC 4.2.3 on OS X Snow Leopard. - Did you have any problems? None, well, except for my divergence in creating my own meta interface for MSM (and Statechart) and the quirks of Boost.PP :-) - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? An in-depth study. - Are you knowledgeable about the problem domain? I have studied all kinds of graphs theoretically, at a deep level, including DFA's, regular graph theory (and category theory), as well as various computational theories. I have used DFA's in most non-trivial projects knowingly for 23 years but a bit longer unknowingly. This latter point is important: I am quite aware and knowledgeable about the necessity (or benefit) of actually making the state machine of a solution explicit. I am not a big fan of extensions of DFA's, though, such as the state charts found in UML specifications. I.e., I think those just diffuse the beauty (if life is not that clean cut, make it so ;-)) SUM: I demanded much better usability or performance out of the second girl to the party, and MSM covers both those aspects, especially with their eUML interface, so I must vote YES to the acceptance of MSM into Boost. Yes, yes, yes! /David

2 2

Re: [boost] [msm] scalability
by Christophe Henry 14 Dec '09

14 Dec '09

Hi Andy, >Christophe, I'm sorry if my 2 cents won't be relevant since I'm not very >familiar with neither MSM I'm thankful for any help. >The most common reason for compiler slowliness/crashiness that I've seen >came from too deep of a template recursion. Agreed ;-) >I'm not totally sure, but I >think that you're using mpl::vector, which, I think, is a form of a type list. AFAIK, this would be mpl::list. mpl::vector is defined as (for example for vector4): template< typename T0, typename T1, typename T2, typename T3 > struct vector4 { typedef aux::vector_tag<4> tag; typedef vector4 type; typedef T0 item0; typedef T1 item1; typedef T2 item2; typedef T3 item3; ... }; So there is no recursion depth, at least not here. I think the culprit would more likely be the many mpl::fold. Thanks, Christophe

2 1

[msm] eUML guard/action location
by Christophe Henry 14 Dec '09

14 Dec '09

Hi Michael, I just remembered the last reason for the current eUML syntax: CurrentState() + cool_event() = DestState() [Guard()]/(action()) It is that eUML row actions/guards can become quite long (something like adjacent_find_(...) ) and I was having difficulties keeping the rows readable. Concretely, I often had to keep the target state on a line by itself, which was costing a line of my screen. With the current syntax, you can get it easier: CurrentState() + cool_event() = DestState() [VeeeeeryLoooooooooongGuard()] /(LooooooooooooooooongAction()) instead of: CurrentState() + cool_event() [VeeeeeryLoooooooooongGuard()] /(LooooooooooooooooongAction()) = DestState() For the tranquility of my conscience, are you still sure you prefer the more logical syntax? Christophe

7 7

[chrono] Boost.Chrono version 0.2.1 Bug fixes + updated documentation
by vicente.botet 13 Dec '09

13 Dec '09

Hi, I have updated Boost.Chrono version 0.2.1 with a lot of fixes. Bug Fixes * Replace INTMAX_C by BOOST_INTMAX_C until boost/cstdint;hpp ensures INTMAX_C is always defined. * Define BOOST_CHRONO_HAS_CLOCK_MONOTONIC when BOOST_CHRONO_WINDOWS_API * Commenting invalid operator declarations * Take care of Boost min/max recommendations * complete qualification when defining nested typedef duration on clocks to avoid the following compile error: ./boost/chrono/chrono.hpp:945: error: declaration of 'typedef class boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> > boost::chrono::system_clock::duration' ./boost/chrono/chrono.hpp:458: error: changes meaning of 'duration' from 'class boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> >' * cleanup of simulated... * warning removal on posix/process_clock.cpp * disable VC++ foolishness * Update Jamfiles to manage with dll * removal of conversion warning in test_duration * manage with MSVC reporting a warning instead of an error when there is an integral constant overflow * Use STATIC_ASSERT specific macro to solve the compile failing issue * Qualify with boost::detail boost::chrono::detail to avoid ambiguities with MSVC Documentation: * Updated documentation. The implementation will eventually work with most C++03 conforming compilers. Tests have been run on Windows with * VC++ 9.0 SP1 Cygwin with * GCC 3.4.4 * GCC 4.3.2 MinGW with * GCC 4.4.0 Getting Boost.Chrono You can get the last stable release of Boost.Chrono by downloading chrono.zip from the Boost Vault You can also access the latest (unstable?) state from the Boost Sandbox. Where to install Boost.Chrono? The simple way is to decompress (or checkout from SVN) the file in your BOOST_ROOT directory. Othesewise, if you decompress in a different directory, you will need to comment some lines, and uncomment and change others in the build/Jamfile and test/Jamfile. Sorry for this, but I have not reached yet to write a Jamfile that is able to work in both environements and use the BOOST_ROOT variable. Any help is welcome. Building Boost.Chrono Boost.Chrono is not a header only library. You need to compile it before use. bjam libs/chrono/build Building an executable that uses Boost.Chrono In addition to link with the Boost Chrono library you need also to link with the Boost System library. Testing In order to test you need to do. bjam libs/chrono/test It will be very kind if someone tested this release with other compilers (Intel) and platforms (Mac) as I'm unable to test them. I expect to been able to test on Linux/gcc-4.1.2 soon. Of course any comments and suggestions are welcome. Best regards, _____________________ Vicente Juan Botet Escribá

1 0

[Spirit/Qi] Sequential-or attribute access in semantic action
by Adam Butcher 13 Dec '09

13 Dec '09

Hi, I am having a bit trouble with the semantic action of a sequential-or parser. Specifically my problem is with accessing the attribute of the sequential-or parser. My first observation is that the documentation at http://www.boost.org/doc/libs/1_41_0/libs/spirit/doc/html/spirit/qi/quick_r… defines the attribute type of (a || b) as tuple<A, B>. Unless I've misunderstood, this must be a typo as they should both be optional (it is never valid for both to be omitted but I would expect that client code be able to determine which out of (a), (b) or (a >> b) were provided.) My real problem is that applying a semantic action to [what I think is] an expression returning a sequential-or parser, results in the _1 referring to the attribute of the last parser on the right-hand-side of the sequential-or rather than the attribute of the sequential-or parser itself. In the following snippet (assume 'start' has an attribute of type S), idxspec = '[' >> (start || (':' >> -start)) [ _val = access_index (_r1,lvalue,_1) ] >> ']'; the function 'access_index' is called with an arg3 of type 'optional<S>' rather than the expected 'tuple<optional<S>, optional<optional<S>>>'. Wrapping the sequential-or expression in a 'repeat' directive as repeat(1)[start || (':' >> -start)] solved the problem but obviously gave me an unwanted sequence (albeit with only one element). The attribute type of the above came out to be vector<tuple<optional<S>, optional<optional<S>>>> as expected. To remove the sequence I created a parser directive called 'identity' following the form of 'repeat' which I have attached. My final rule is now idxspec = '[' >> identity[start || (':' >> -start)] [ _val = access_index (_r1,lvalue,_1) ] >> ']'; which is working fine; the _1 delivers an argument of type tuple<optional<S>, optional<optional<S>>> as required. However, I would have expected this behaviour from the first expression. Is this a a proto issue, a spirit issue or have I completely misunderstood something somewhere? It may or may not be relevant but I am using both spirit.classic and spirit 2.1 in the same file. This is historical and will be fixed in time but I guess it could be important. So far I have had no problems with the combination however. Additional info: I am using gcc 4.4.2, stlport 5.1.3 and boost 1.41.0. Regards, Adam

2 6

[chrono] New Features + Bug fixes + Updated documentation
by vicente.botet 13 Dec '09

13 Dec '09

Hi, I'm pleased to annonce the new version of the Boost.Chrono library. Even if the library is not yet ready for review I wanted to share it with you. The library can be downloaded from the vault http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html. For the moment I'm not able to test it on Windows and Mac platforms. Could you check if there are some regressions on Windows or on Mac platforms? Of course, any comments or suggestions are welcome. If there is a volontary review manager that can start inspecting the library s/he is also welcome :). This library is based on the Beman's boostified version of the probe of concept of Howard. Many thanks to Howard the originator of the library and to Beman to start the boostification. Next follows the contents of the library and the updates of the new version Version 0.1.0, April 29, 2009 Beman's boostified version Features: * The C++0x Standard Library's class common_type. * The C++0x Standard Library's compile-time rational arithmetic. * The C++0x Standard Library's time utilities, including: * Class template duration * Class template time_point * Clocks: * system_clock * monotonic_clock * high_resolution_clock * Class template timer, with typedefs: * system_timer * monotonic_timer * high_resolution_timer * Process clocks and timers: * process_clock, capturing real, user-CPU, and system-CPU times. * process_timer, capturing elapsed real, user-CPU, and system-CPU times. * run_timer, convenient reporting of process_timer results. Version 0.2.0, December 8, 2009 + New Features + Bug fixes + Updated documentation Features: * Added ratio construction and assignment from an equivalent ratio (LWG 1281. CopyConstruction and Assignment between ratios having the same normalized form) * Added nested ratio typedef type (LWG 1281. CopyConstruction and Assignment between ratios having the same normalized form) * Added BOOST_CHRONO_HAS_CLOCK_MONOTONIC macro to state if monotonic_clock is provided on a platform. * Added duration operator% (LWG 934. duration is missing operator%) * Complete duration operator* and operator/ Implementation: * Use INTMAC_C to name intmax_t constants instead of LL. * Separate chrono.cpp on # files win/chrono.cpp, mac/chrono.cpp and posix/chrono.cpp to make easier the maintenance on different platforms. * Separate process_clock.cpp on # files win/process_clock.cpp, mac/process_clock.cpp and posix/process_clock.cpp to make easir the maintenace on different platforms. * Added the error_code prototype for monotonic_clock::now for mac/chono.cpp * Fully implement mac/chrono.cpp with error handling. * Take care on POSIX systems when CLOCK_MONOTONIC is not defined. Documentation: * The documentation is written now using quick-book using as base "N2661 - A Foundation to Sleep On". Fixed Bugs * operator/ was ambiguous: Disambiguate duration operator/ * CLOCK_MONOTONIC is not defined with cygwin/gcc 3.4: Disable code when BOOST_CHRONO_HAS_CLOCK_MONOTONIC is not defined. * result of metafunctions ratio_multiply and ratio_divide were not normalized ratios: Use of the nested ratio typedef type on ratio arithmetic operations. * Copy constructor from similar duration masked the defaulted operations: Added duration defaulted implementations Note that the comon_type class should be integrated by Boost.TypeTraits, class ratio will be proposed as a standalone library Boost.Ratio, and the Timer and Process clock part could be proposed as an update of Boost.Timer. Best regards, _____________________ Vicente Juan Botet Escribá

4 11

Re: [boost] [msm] Review
by Christophe Henry 13 Dec '09

13 Dec '09

Hi Darryl, If you don't mind, I'll start by answering the last question, it'll make the rest of the discussion easier. >Now I'm confused. Are you: > >a) Convinced the suggestion is without merit? No. After reading your last mail, I see a bit better, though I'm not sure I can follow all of it. >b) Waiting for a concrete example? Yes! Exactly. >c) Convinced I'm an idiot that can't figure out how to use msm effectively >(in which case, consider this a request for better docs)? No. Sorry if I gave you the feeling the correct answer was a) or b). I don't mind criticism, any of it, justified or not, as long as it doesn't stay vague and instead goes to concrete, argumented points. Vague negative comments bring little to the review and contribute to giving an incomfortable feeling to all participants. Constructive remarks are, on the other side, highly welcome! That's reason #1 for a review. I sometimes, like yesterday, take part in several parallel discussions, so I have little time left for remarks I cannot start anything with. Sorry about it, it's the negative side of the review. I'd be thankful if potentially useful but vague ideas were kept for a more quiet time. So now, to the concrete parts of your remarks. >I genuinely don't see why msm needs to instantiate state objects it owns at all. If this is the point, then it is a solvable problem. Clearly, it doesn't strictly need. It's just a feature, which is in some contexts very useful. The main one is to be able to save some data in the states. This data can then be generically accessed by the generic functors, thus increasing reuse and encouraging clean code. The functor front-end will be your friend in this case. The same with eUML, but it doesn't have to be eUML. The second reason would be entry/exit: >I suggest spelling them enter<state>(machine) and exit<state>(machine) > or machine.enter<state>() and machine.exit<state>(). Of course, this would be a solution. It's actually an interesting one, and if you don't mind, we'll keep for later (see below). Do we agree that it makes the machine slightly less readable? The 3rd reason is state reuse. This brings us to: >What does reuse of a state in msm mean? Interesting question, which is sadly ignored by many fsm frameworks. A case would be when you want to avoid doing the same case again and again. You could then define a state hierarchy, even (gulps) OO-like for this (or better some template policy magic). For example, I personally often add some logging in debug mode, so that I know what happened in my system. The visitor is another good example of it. I hope that after having a look at it, you'll see the interest you can gain from it. You might have easily missed another case in the doc. If you have a look at iPodSearch and iPodSearchEuml, you'll see where I want to go next. To states which implement STL algorithms. You will then be able to write complex algorithms by simply moving some predefined states on a diagram. I plan to call it the STL (State Template Library ;-) ). While this is for the future, I'll need independent, reusable states for it. >No. For the record, in my opinion, the single the worst feature of >statechart is the necessity to use custom reactions to implement some fsm <constructs. This was a subject of much discussion during the Statechart >(FSM) review iirc. I see. Then I probably misunderstood your point. > Can you perhaps explain why flags are needed? Sure. If you look at the statechart doc, you'll see some state_cast. I personally find it not beautiful in my code. It's also hard to maintain when your fsm structure changes. Flags are faster, require no rtti, are more model-oriented as states define themselves their "property" and makes user code easier/smaller to read. It's even supported by eUML for better model-orientation. I wanted to handle the entry/exit discussion separately. Hopefully I managed to convince you why states are useful and their instanciation brings some advantages. Of course, there is a price to pay, though a small one (if without data, 1 byte/state). This is in most cases not a huge cost. I agree there are cases where the price is still too expensive. I also agree, that the one current MSM back-end is not a solution for all problems, otherwise I would have written in stone that there is one backend and we'd be done. The MSM backend is a fully optimized machine, trying to pack as many features as possible at the lowest possible cost. There are however cases, where one would be ready to give up some features like state reuse and generic functors in exchange for reduced costs. For such cases, there is room for a mini-MSM backend (name from Barend Gehrels ;-) ). And in this case, your entry/exit solution appears a viable, interesting one for which I am thankful. When preparing the review, I had several possibilities: - make the current MSM backend, with lots of features, thus proving that the approach of the MPL book was a great one. - make a reduced, smaller cost version, with the certainty of being criticized for not having enough features (see review from FSM) and rending a disservice to the book. - make a 3rd one, more dynamic, which I want to do since a while. - make no review until all possible back-ends are done and make everybody wait at least one more year. Do we agree that solution 1 seems the more logical? I hope we managed to find a common ground and that a fruitful discussion can take place. Christophe

2 1

[test] new feature - colored output
by Gennadiy Rozental 13 Dec '09

13 Dec '09

Hi, I've implemented a change in regular human readable log and report outputs. You now have an ability to tell the unit test framework to produce colored output. New boolean runtime parameter is added: Environment variable: BOOST_TEST_COLOR_OUTPUT Command-line long: --color_output Command-line short: -x. By default the feature is disabled. Any comments are appreciated. Specifically: how does this feature works in different environments and if there is a way to make MS compiler to work properly (gcc on windows works fine in Windows shell, while msvc build does not) Gennadiy

1 0

[fiber] new version 0.3.0 with future and fiber-migration
by Oliver Kowalke 12 Dec '09

12 Dec '09

Hi, I've uploaded boost.fiber 0.3.0 - it supports future/packaged_task (adapted from Anthony), migrating fiber between schedulers (event running in different threads) and sync. primitives like barrier etc. The spiining sync. objects can be used for snyc. fibers running in different schedulers (running in different threads). Please see examples: ping_pong_mt, migrate_mt, future_mt and barrier_mt regards, Oliver change.log 0.3.0: ------ - support of barrier (more efficient in on scheduler) and spin::barrier (sync .between threads possible) - support of future and packaged_task (example future_mt) - explicit migration of fibers between two schedulers (even if schedulers are in different threads - see example migrate_mt) - locks replaced by locks implementation from boost.thread - introduction of spin::mutex, spin::condition, spin::auto_reset_event, ... (can be used to sync fibers between threads see ping_pong_mt example) - introduction of mutex, condition, auto_reset_event, ... (objects bounded to one scheduler, but more efficient than spin counter-parts) - refactoring of internal classes

1 0

ACID transactions/flushing/MySQL InnoDB
by Stefan Strasser 12 Dec '09

12 Dec '09

hey, this is not a boost question, but it is for the development of a boost library, so maybe a database expert on the list could help me out? I've been benchmarking some test cases of my library against MySQL InnoDB, which isn't even apples to oranges anymore, but nevertheless gave some insights. what I find surprising is the performance of MySQL for small transactions. while my library spends 90% of its time waiting for the disk to flush a transaction, InnoDB uses 100% CPU and barely uses any disk. I've reduced the calls to fsync() for small transactions to 1 call per transaction after some sequential writing, so I'm wondering how MySQL accomplishes this? by definition there must be a flush per transaction, unless you loosen the requirements of the D in ACID. Is that what InnoDB is doing? the only way I see to reduce flushes even more is combining some transactions. but after a power failure some of those transactions can be lost even though they haven reported as successfully committed. I have not yet examined their source code yet. the MySQL documentation doesn't say anything about loosening Durability. (although you have to look pretty hard to see that the default isolation level isn't Serializable either.) thanks in advance, Stefan

5 17

[Boost-config] Add pgi-9.0 threading support
by Belcourt, Kenneth 12 Dec '09

12 Dec '09

Hi John, I've attached a patch to enable threading support with pgi-9.0 (I'm trying to resurrect the pgi tester). Does this look okay to commit? -- Noel

2 1

bug in boost::variant?
by Zachary Turner 11 Dec '09

11 Dec '09

I'm using boost 1.41. I use a variant to store a symbolic representation of an algebraic expression, wrapped inside of a master "node" class. Like this: struct expr_node { friend class constant; friend class variable; friend class arithmetic_op; friend class exponent; friend class special_func; friend class negative; public: template<class T> expr_node(const T& expr) : expr_(expr) { } expr_node& operator=(const expr_node& rhs) { expr_ = rhs; return *this; } private: typedef boost::variant<constant, variable, arithmetic_op, exponent, special_func, negative> node_type; node_type expr_; }; Of course, this is a recursive definition, because exponent, arithmetic_op, etc also contain expr_node members. At some point, I flatten the tree structure across either addition or multiplication, the result of which is a std::list<expr_node>. So in this example, if my expression is 2 * x * 2 * x^x * (2+x)^2 * (1 + x) this becomes the list [2, x, 2, x^x, (2+x)^2, 1+x]. I then use std::partition() to organize this list into the desired order according to the node type. This is where the strange behavior comes in. As you can see there are no negatives in this expression, and indeed, I can verify this is indeed the case in my code as well with: bool expr_node::is_negative() const { return boost::get<negative>(&expr_); } ... BOOST_ASSERT(std::find_if(terms.begin(), terms.end(), boost::bind(&expr_node::is_negative, _1)) == terms.end()); This assert passes. However, Immediately executing std::partition(terms.begin(), terms.end(), boost::bind(&expr_node::is_constant, _1)); BOOST_ASSERT(std::find_if(terms.begin(), terms.end(), boost::bind(&expr_node::is_negative, _1)) == terms.end()); triggers the assert. So something is going wrong involving copying the variants. Every class has both a copy constructor and an assignment operator. Examining the exact contents of the list both before and after the partition, the which_ fields are [0,1,0,3,3,2] (before), and [0,5,5,3,3,2] (after). Putting a breakpoint in all of the negative constructors, I can get a callstack for the first time a 'negative' is constructed. The callstack is as follows: negative::negative(const expr_node & arg={...}) Line 747 C++ node_type::convert_construct<expr_node const >(const expr_node & operand={...}, int __formal=1, int __formal=1) Line 1298 + 0xf bytes C++ node_type::node_type<expr_node>(const expr_node & operand={...}) Line 1367 C++ node_type::assign<expr_node>(const expr_node & rhs={...}) Line 1609 + 0xc bytes C++ node_type::operator=<expr_node>(const expr_node & rhs={...}) Line 1620 C++ expr_node::operator=(const expr_node & rhs={...}) Line 171 C++ std::swap<expr_node>(expr_node & _Left={...}, expr_node & _Right={...}) Line 23 C++ std::iter_swap<term_list::_Iterator<0>,term_list::_Iterator<0> >(term_list::_Iterator<0> _Left={...}, term_list::_Iterator<0> _Right={...}) Line 594 + 0x17 bytes C++ std::_Partition<term_list::_Iterator<0>,boost::_bi::bind_t<bool,boost::_mfi::cmf0<bool,expr_node>,boost::_bi::list1<boost::arg<1> > > >(term_list::_Iterator<0> _First={...}, term_list::_Iterator<0> _Last={...}, boost::_bi::bind_t<bool,boost::_mfi::cmf0<bool,expr_node>,boost::_bi::list1<boost::arg<1> > > _Pred={...}) Line 1838 + 0x4d bytes C++ std::partition<term_list::_Iterator<1>,boost::_bi::bind_t<bool,boost::_mfi::cmf0<bool,expr_node>,boost::_bi::list1<boost::arg<1> > > >(term_list::_Iterator<1> _First={expr_={...} }, term_list::_Iterator<1> _Last={expr_={...} }, boost::_bi::bind_t<bool,boost::_mfi::cmf0<bool,expr_node>,boost::_bi::list1<boost::arg<1> > > _Pred={...}) Line 1847 + 0x64 bytes C++ expr_node::organize() Line 213 + 0x77 bytes C++ Perhaps it's related to the implementation of swap() for variants? If a more detailed code sample is needed, I can upload this entire program to a web server for someone to download. Zach

2 2

Re: [boost] [MSM] compile errors
by Christophe Henry 11 Dec '09

11 Dec '09

Hi Michael, >FWIW. gcc-4.3.3 compiles SimpleTutorial.cpp just fine but has issues with >SimpleTutorialEuml.cpp. Pages and pages of a compiler babble about >boost::fusion::void_ and mpl_::na. > >Should I not be using boot 1.41? I just tried the version with old syntax and with the new one, with gcc-4.4 and boost 1.41 and got no warning, even in pedantic mode (excluding a few in boost/integer_traits.hpp), so I'm scratching my head. Christophe

1 0

interprocess named condition
by Jan 11 Dec '09

11 Dec '09

I'm guessing a named condition has to be used in a shared_memory_object, with a mapped_region. Like the anonymous condition? Which might explain the problems I was having with it before.

1 0

Review Queue Needs Attention
by Tom Brinkman 11 Dec '09

11 Dec '09

Paul A. Bristow said >> Yes - *exposure* is the key to inspiring authors to refine their contributions. >> I've argued for some time for a 'experimental' or 'candidate' status. >> (And a state not damned with faint praise like 'unstable' - which is perhaps >> better described as 'likely_to_be_improved' rather than actively 'not stable'). >> We'd need a simpler review process to agree to put a library into this >> 'candidate state' from the 'sandbox state'. >> This would mean that when libraries are reviewed for full acceptance, they >> should have received much more use, feedback and refinement, and be really ready >> for use by those who want a 'release quality' stable product - including decent >> documentation. Agreed. Here is the current review queue. 1) Lexer Ben Hanson 2) Shifted Pointer Phil Bouchard 3) Logging John Torjo 4) Join Yigong Liu 5) Pimpl Vladimir Batov 6) Task Oliver Kowalke 7) Endian Beman Dawes 8) Meta State Machine (MSM) Christophe Henry 9) Conversion Vicente Botet 10) Sorting Steven Ross 11) GIL.IO Christian Henning 12) AutoBuffer Thorsten Ottosen 14) Log Andrey Semashev 15) String Convert Vladimir Batov 16) Move Ion Gaztañaga 17) Containers Ion Gaztañaga 18) Interval Containers Joachim Faulhaber 19) Type Traits Extensions Frédéric Bron 20) Interthreads Vicente Botet 21) Bitfield Vicente Botet 22) Lockfree Ivo 23) Faster Signam slots Helge Bahmann The number of review requests is far outstripping the number of volunteer review managers. Considering about six libraries per year are getting reviewed, this is well over a three year back log. And this does not even include some other libraries that have been discussed, but not included. There are alot of good ideas here, they should not be ignored. Some of these libraries have been in the queue for over 18 months. My idea to fix this is well known. I would like something similar to Paul's approach. Those of you who have argued against a "non-stable" branch of boost, how would you propose fixing this "review queue" problem.

11 25

Re: [boost] [MSM] Comparison with ad-hoc FSM implementation
by Christophe Henry 11 Dec '09

11 Dec '09

Hi Phil, >> I fully agree with Michael's point that more complicated constructs >> are really messy to implement with ad-hoc techniques. >Do we have any concrete examples of larger problems anywhere? I would >be interested to see them so that I can consider how I would implement them. Sure. Please have a look in the MSM doc at the MsmSession_Handout.pdf. At the last page, you'll see the description of an iPod nano. This example was presented in the BoostCon hands-on session. We managed to write a fsm representing a full mock-up in 90mn (of course we cheated a bit as I had prepared something). And we immediately generated the code. Do you think it would be possible with an ad-hoc solution in such a short time (or even double more)? >> But on the construct presented by Phil I personally find a lot to criticize. >> First of all, it is a mess. > >I would be much happier if you could please avoid using language like this. Please excuse me but I fail to understand what you mean. Being not a native speaker, I'd greatly appreciate some help as I wasn't under the impression to use a rude language. >> what really bugs me is the mix of fsm structure with >> character processing. > >But in this application, the FSM is driven by the characters that are >received - that is what it is all about. Why do you want to separate >it out into two things? Because I consider that the purely fsm part of the application should be separated from the character analysis. A close look at the functor will show you that it handles character analysis and then generates an event. The fsm then decides what to do with the event. A different fsm can choose to reuse the code in another context. I find this pretty natural. Character analysis on one side, handling on the other. >>>void process_event(const character_received_event& e) { .... >>>void process_event(const sigwinch_event& e) { .... >> >> Having to write overloads in a template word??? No, thanks! > >Can you please explain why ? I find it pretty clear that template <class Event> void process_event(Event const&); constitutes a better interface than (adding more events): void process_event(const character_received_event& e) { .... void process_event(const sigwinch_event& e) { .... void process_event(const some_other_event& e) { .... void process_event(const yet_another_other_event& e) { .... etc. >Consider the transition from the seen_escape state to the normal state, >which occurs at the end of an escape sequence. For this you would need >a last_char_of_escape_sequence event. You would need to consider this >in your case statement above (e.g. letters normally do terminate the >escape sequence but digits normally don't). But this categorisation >happens for received characters whatever state the machine is currently >in. So in the transition table you would need rules like this: > >row < normal, escape_char, seen_escape >, >row < normal, last_char_of_escape_sequence, normal >, >row < normal, not_last_char_of_escape_sequence, normal >, >row < seen_escape, escape_char, seen_escape >, >row < seen_escape, last_char_of_escape_sequence, normal >, >row < seen_escape, not_last_char_of_escape_sequence, seen_escape >, The example seems to grow at will, but the issue stays the same. I operated a seemingly small change, concretely: case escape: state = seen_escape; break; was replaced by a functor containing: case escape: fsm.process_event(escape_char()); break; Which I can repeat any time you set the state variable inside a case statement. The only difference is that now, the code analysing the character has no idea of the fsm structure, which means it can be reused in another fsm. This is made possible by the use of a functor. Otherwise, it's your algorithm, only organized in such a way that you have a better chance of reuse in another fsm context. Whatever, I just wanted to show another way of implementing the same algorithm using MSM, with the same performance and a better chance of reuse. A bigger application will probably illustrate better the strength of MSM. If you look at the iPod example, you'll see how the library will do things which are very hard with an ad-hoc solution. I'd be interested to see how an such implementation would solve this problem. I think it might constitute a more interesting discussion base. Regards, Christophe

2 1

[BoostCon 2010] Submission deadline extended
by Hartmut Kaiser 11 Dec '09

11 Dec '09

In 2010 BoostCon celebrates its 4th anniversary in Aspen. You are invited to submit a paper or a session (see the original call for participation here: http://www.boostcon.com/community/wiki/show/Start/) for BoostCon 2010, Aspen on May 10 - May 14th, 2010. Please, see http://www.boostcon.com for more information. Important dates: Proposal submissions Extended to January 3, 2010 Proposals decisions sent January 25, 2010 (tentative program available) Fully scheduled program available February 10, 2010 Session materials due April 15, 2010 Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

Re: [boost] [MSM] compile errors
by Christophe Henry 11 Dec '09

11 Dec '09

>As we saw over in the "[fusion] change on trunk breaking proto" thread, >even VC10 has bugs that cause random failures in proto's tests. Using >proto isn't necessarily a talisman against compile errors. Sure. In this case, proto has only a very limited role, at most the one of a trigger. Specifically, VC8 has problems with enable_if for template class specializations. Interestingly, it has a problem with Process2_ eventhough it doesn't even use it, just including the header is enough to get the bug. Even more interesting, the next template specialization (Get_Flag_) doesn't seem to disturb the compiler... Anyway, all VC compilers suffer from the same disease. Most template constructs will manage to compile once, but repeat the operation too much and it gives up. I'd bet that Microsoft uses tons of test cases which try any construct once. I actually only try to support eUML for VC8 to honor the fact that it implemented a typeof back in 2005. Christophe

1 0