December 2009 - Boost - lists.preview.boost.org

[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

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

11 Dec '09

Hi Michael, >I'm trying to compile SimpleWithFunctors.cpp or SimpleTutorialEuml.cpp >with VC8. Using the original review source code package (not the new >eUML syntax). VC8 will drive me crazy. Now it starts complaining about stuff it doesn't use :( I just committed in the sandbox a fix for VC8 (euml/common.hpp). This should now work. But VC8 will not manage much more than this tutorial. As I wrote, it has very limited eUML support. >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. I tried only until 1.40. I just checked (with g++4.3 and 1.39, and with g++4.4 and 1.40) and it works without warning, so either we have different warning options (I have the default) or there is a surprise in 1.41. I'll have a look at it. Sorry for the annoyance. Christophe

3 4

[Date_Time] acquiring accurate high resolution system time
by Jean-Gerard Beauport 11 Dec '09

11 Dec '09

For middleware purposes we have been looking at using Boost as our date/time library. It seems to cover most of our requirements. Now it has been brought to our attention that one of our requirements would be to be able to get the system time at a high resolution. Although using solely the high performance counter is a solution to this, it has its flaws. We have read an article that gives a solution that overcomes some of the problems inherent to using the performance counters, and combines/synchronizes these counters with system time to achieve better resolution. The following is a link to the article that tackles the subject (on Windows): http://msdn.microsoft.com/en-us/magazine/cc163996.aspx Has solving this type of issue been considered in Date_Time? Is it worth looking into? With these questions, I am trying to avoid venturing in something that may have already been experimented with and concluded on. I have noticed in the boost::date_time code that there is the microsec_clock::local_time() call that should provide high resolution time, but in looking at the code I do not quite understand how that is achieved with accuracy. I am trying to understand the file_time_to_microseconds() function in filetime_functions.hpp, and I have difficulty to understand how counting microseconds difference from Jan-01-1601 to Jan-01-1970 comes into play in counting the microseconds from epoch to "now". Can someone clarify this? I thank you in advance for taking the time to answer my few questions. Kind Regards, John

1 0

[MSM] compile errors
by Michael Caisse 10 Dec '09

10 Dec '09

Christophe - I'm trying to compile SimpleWithFunctors.cpp or SimpleTutorialEuml.cpp with VC8. Using the original review source code package (not the new eUML syntax). I have the same errors when compiling each: d:\boost\boost_1_41_0\boost/msm/front/euml/common.hpp(1305) : error C2953: 'boost::msm::front::euml::Process2_<ToProcessEvt,Value,Param1,Param2,Param3,`global namespace'::boost::disable_if<`global namespace'::boost::mpl::or_<`global namespace'::boost::is_same<Param2,void>::type,`global namespace'::boost::mpl::not_<`global namespace'::boost::is_same<Param4,void>::type>::type>::type>::type>' : class template has already been defined d:\boost\boost_1_41_0\boost/msm/front/euml/common.hpp(1243) : see declaration of 'boost::msm::front::euml::Process2_<ToProcessEvt,Value,Param1,Param2,Param3,`global namespace'::boost::disable_if<`global namespace'::boost::mpl::or_<`global namespace'::boost::is_same<Param2,void>::type,`global namespace'::boost::mpl::not_<`global namespace'::boost::is_same<Param4,void>::type>::type>::type>::type>' d:\boost\boost_1_41_0\boost/msm/front/euml/common.hpp(1342) : error C2953: 'boost::msm::front::euml::Process2_<ToProcessEvt,Value,Param1,Param2,Param3,`global namespace'::boost::disable_if<`global namespace'::boost::mpl::or_<`global namespace'::boost::is_same<Param2,void>::type,`global namespace'::boost::mpl::not_<`global namespace'::boost::is_same<Param4,void>::type>::type>::type>::type>' : class template has already been defined d:\boost\boost_1_41_0\boost/msm/front/euml/common.hpp(1243) : see declaration of 'boost::msm::front::euml::Process2_<ToProcessEvt,Value,Param1,Param2,Param3,`global namespace'::boost::disable_if<`global namespace'::boost::mpl::or_<`global namespace'::boost::is_same<Param2,void>::type,`global namespace'::boost::mpl::not_<`global namespace'::boost::is_same<Param4,void>::type>::type>::type>::type>' Something that I'm doing? I'll be trying on gcc soon. Thank you - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 1

[smart_ptr] quick allocator broken
by Juergen Hunold 10 Dec '09

10 Dec '09

Hi ! I just got round to finally debug some mysterious failures on my project against current trunk. It seems that ------------------------------------------------------------------------ r57953 | pdimov | 2009-11-26 21:55:05 +0100 (Thu, 26 Nov 2009) | 1 line Add error checking to lwm_pthreads.hpp. Refs #2681. ------------------------------------------------------------------------ broke BOOST_SP_USE_QUICK_ALLOCATOR support. All my programs (and tests) using smart_ptr fail with /rmc/hunold/packages/boost/boost/smart_ptr/detail/lwm_pthreads.hpp:73: boost::detail::lightweight_mutex::scoped_lock::scoped_lock(boost::detail::lightweight_mutex&): Assertion `pthread_mutex_lock( &m_ ) == 0' failed. on exit. Steps to reproduce: I've attached against the Jamfile.v2 in libs/test/test which adds an extra feature "quick-allocate" with values "off" "on" Running "bjam quick-allocate=on" will start a build using the quick allocator and reveal 4 failures (log attached). I'm lost here. All I have figured out so far is that the destruction of static object might be involved here. But this migt be a red herring. Any ideas on this ? This is catched by the regression tests as obviously noone ist running a build with BOOST_SP_USE_QUICK_ALLOCATOR enabled. I can provide gdb stacktrace when needed. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 3

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

10 Dec '09

Hi, Michael Caisse wrote: >This concept is difficult (messy) to implement with ad-hoc techniques. >I personally find that the richness provided by some of the modeling >language constructs produces very simple solutions for what can often >be messy problems to solve. It brings an elegance to the solution >space that cannot be found in just states and transitions alone. >It is the richness of the modeling language that helps one solve more >complex problems without complexity. > >Sure, in these simple toy examples the ad-hoc switch statement looks >as good if not better than a complex library. But as soon as we start >making something that is industrial proof with all the error cases >and whatnots ... well things start getting more complicated and >I personally start looking for some additional constructs to help out. I fully agree with Michael's point that more complicated constructs are really messy to implement with ad-hoc techniques. And the real power behind a fsm library is the abstraction from code to move on to higher abstractions. But on the construct presented by Phil I personally find a lot to criticize. First of all, it is a mess. The code is long and even while the machine is so trivial that you could almost do it without a fsm, it must be quite hard to follow if one adds all what was left out for demonstration purposes. Second, and what really bugs me is the mix of fsm structure with character processing. Such a code is not to be reused (if one doesn't count a selective copy/paste). This is made even worse by the fact that this is obviously GUI code and such processing must happen several times in different modules. I also don't like: >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! I think the only thing I like in it is the O(1). Phil Endecott wrote: >How would you do this with MSM? Something like this presumably: > >row < normal, character_received_event, seen_escape, none, &is_escape_char >, >row < normal, character_received_event, normal, &insert_at_cursor_and_advance >, >row < seen_escape, character_received_event, normal, &cursor_home, &is_H >, >row < seen_escape, character_received_event, normal, none >, >row < any, sigwinch_event, unchanged, &resize_screen > Apart from the fsm structure and syntax errors, which are irrelevant to the discussion, yes, I could do something like this if performance were uncritical in this part of the application and I wanted a chance to play with eUML. But more likely, I wouldn't do that. Instead, if performance was an issue I'd probably keep the second switch/case (the switch on character), pack it inside a nice generic functor which would in no case do this: >case escape: state = seen_escape; break; Because this means mixing character processing with fsm structure. It'd be something like (as entry functor. Could be as transition functor too): struct CharTypeProcessing: euml_action<CharTypeProcessing> { template <class Event,class FSM,class STATE> void operator()(Event const&,FSM& fsm,STATE& ) { switch (c) { case escape: fsm.process_event(escape_char()); break; .... more special characters like tab, newline etc .... default: fsm.process_event(normal_char(c) ) ;break; } } }; I don't go more into details but I'm sure you get the idea. We now have a generic functor, which can be reused in any state or fsm without any knowledge of the structure. It can be documented as: name: CharTypeProcessing description: checks for special characters. Triggers event normal_char(char value) if a normal char, escape_char if escape, etc. And now, any other developer can reuse it, without having to dig into the code to get the part he needs. But what really really strikes me is that it's already Phil's second implementation of a fsm on 2 examples. And a pretty different one than the first! This means double work, double debugging. Add this to the fact that the character processing is also not reusable (mixed with fsm structure, as we saw) and I think I'll be enjoying a latte with a choco-croissant (my favorite) while other developers will still try to find why Phil's code doesn't work for them (hint: they surely made a mistake in their copy/paste. Tsss...). >You are welcome to try to >convince me that it has benefits that I have not yet seen.... Sorry but I won't try because I doubt, from experience, that someone who will have spent a long time on his multiple switch/case will want to give up this work too fast. But it's really ok for me, as I said, I wrote MSM for people like me, who can't see a double switch/case without a strong uncomfortable feeling. If you feel more comfortable with it, great for you! Only, if you ever look for a copy/paste error for hours, I hope you'll picture me with my latte and choco-croissant and switch back to MSM. I'll be happy to share a latte with you ;-) Regards, Christophe

2 1

looser throw specifier for virtual boost::exception_ptr::~exception_ptr()
by Frédéric Bron 10 Dec '09

10 Dec '09

Tried 1.41 today. Seems like the thread library is not compatible with gcc-3.4.4 anymore (here on cygwin). However I do not see such error in trunk tests with gcc- 3.4.3 so I suspect something else. Any idea? In file included from .../boost/thread/future.hpp:12, from .../boost/thread.hpp:24, .../boost/exception_ptr.hpp:43: error: looser throw specifier for `virtual boost::exception_ptr::~exception_ptr()' .../boost/exception/detail/exception_ptr_base.hpp:27: error: overriding `virtual boost::exception_detail::exception_ptr_base::~exception_ptr_base() throw ()' Frédéric

2 2

uuid docs, minor typo
by Ralf W. Grosse-Kunstleve 10 Dec '09

10 Dec '09

I think there is a minor typo in the uuid docs: A UUID, or Universally unique identifier, is indended to uniquely identify ^^^^^^^^ intended Ralf

2 1

Age-based reference counting solves the problem of cyclic references?
by Achilleas Margaritis 10 Dec '09

10 Dec '09

Hello all. I've been playing a little with reference counting ideas, and I came up with an idea that might solve the problem of cyclic references: if a smart pointer remembers all the objects it has touched, and if it knows its age and the age of the objects it has pointed to, the smart pointer can delete the objects if its age is older than the objects it has pointed to. Here is an example: #include <list> #include <iostream> using namespace std; unsigned age = 0; class aged { public: aged() : m_age(-1), m_deleted(0) { } aged(const aged &c) : m_age(-1), m_deleted(0) { } void operator = (const aged &a) { } private: unsigned m_age; unsigned m_deleted; template <class T> friend class ptr; }; template <class T> class ptr { public: explicit ptr(T *value = 0) : m_value(value), m_age(++age) { _acquire(); } ptr(const ptr<T> &p) : m_value(p.m_value), m_age(++age) { _acquire(); } ~ptr() { _release(); m_value = 0; _expire(); } T *operator ->() const { return m_value; } void reset() { _release(); } ptr<T> &operator = (const ptr<T> &p) { _release(); m_value = p.m_value; _acquire(); return *this; } private: T *m_value; unsigned m_age; list<T *> m_remembered; void _acquire() { if (m_value && m_value->m_age > m_age) m_value->m_age = m_age; } void _release() { if (m_value && m_value->m_age >= m_age) m_remembered.push_back(m_value); } void _expire() { for(list<T *>::iterator it = m_remembered.begin(); it != m_remembered.end(); ++it) { T *obj = *it; if (obj->m_age >= m_age && !obj->m_deleted) { ++obj->m_deleted; obj->~T(); --obj->m_deleted; if (!obj->m_deleted) ::operator delete(obj); } } } }; class Foo; class Bar : public aged { public: ptr<Foo> m_foo; Bar() { cout << "Bar()\n"; } ~Bar() { cout << "~Bar()\n"; } }; class Foo : public aged { public: ptr<Bar> m_bar; Foo() { cout << "Foo()\n"; } ~Foo() { cout << "~Foo()\n"; } }; int main() { { ptr<Foo>foo0; { ptr<Foo> foo1(new Foo); foo1->m_bar = ptr<Bar>(new Bar); foo1->m_bar->m_foo = foo1; ptr<Bar> bar1(foo1->m_bar); { ptr<Foo> foo2 = foo1; foo2->m_bar = ptr<Bar>(new Bar); foo0 = foo1; foo1.reset(); } } } return 0; } While there is a referential cycle (foo->bar->foo), all objects are eventually deleted. While the above example doesn't use reference counting, it can be combined with reference counting to solve the issue of cyclic references: objects that their reference count reaches 0 are deleted normally; objects with cycles remain in memory until the oldest pointer to them goes out of scope. In most cases, What do you think?

2 1

[MSM] Comparison with ad-hoc FSM implementation
by Christophe Henry 10 Dec '09

10 Dec '09

Hi Phil, >switch ((state<<8) | event) { > case (Stopped<<8)|play: start_playback(); state=Playing; break; > case (Stopped<<8)|open_close: open_drawer(); state=Open; break; >etc. etc. >The greatest advantage of this ad-hoc style is that it is readable >by anyone who has even the most basic understanding of C++ without >the need to learn a new library, and its exact behaviour is immediately >evident. It is also likely to compile and run quickly. > >I have no doubt that MSM has many benefits compared to this. Perhaps >it would be useful to spell them out? The question is of course slighty provocative but still valid. The answer will be quite long, sorry about that. I won't say that your solution is not good. Actually if someone is happy with such a solution, great for him. If you check the review from Franz Alt, you'll see the source code generated by Rhapsody, which is not very different from this one, the O(1) double-dispatch excluded. And it's at least way better than non-formal state machines which I happen to see in production code again and again. A state machine library, including MSM, is made for people who are not happy with such an approach. I wrote MSM out of sheer frustration with Statechart's inability to provide me with what I was looking for, and out of admiration for the solution presented in the MPL book. I only hoped that others felt like me and would like an alternative. Concretely, what I was looking for: - a descriptive, expressive and declarative state machine syntax. - most of UML features which are hard to code with a switch/case dispatch. - a library with the explicit goal of supporting a Model-Driven-Development process - enough speed so that it'd be hard to reject a state machine simply on speed grounds (usual excuse). Next, you wil ask me what UML features I deem so important that it justifies a library. My personal favorites (order by what I use most): - events containing data. In your case, you are more or less forced to choose between the O(1) (which you did) and forgo event data or the O(n) (chosen by Rhapsody) at a speed cost. Metaprogramming techniques allow us a O(1) with event data. - actions/guards. Luckily, they are easy to implement in a switch/case. - orthogonal regions. I often use them for error handling and they greatly make the machine more readable by reducing the number of transitions. Also hard to get with a switch/case. - submachines (makes the code cleaner). Implementing them inside a switch case is simply horrible. Soon, you need to hide them in subclasses so we are already going in the direction of a library. - flags. Will make the calling code easier - exit points. Not my favorite, but always needed. Will quickly make your switch/case implementation hard to follow. - anonymous events. Hard to write with a switch/case dispatch. Luckily for your case, not everybody likes them. - history. Easy to implement in a switch/case (as long as you don't need them event-dependent) but doesn't make your code any more readable Of course, like always, developers use only 20% of all UML features. But it's never the same 20%, so what you need depends on your "coding" style. And if you want to implement all these features in a switch/case, your code will quickly become terrible. You'll have to issue guidelines on how to implement them, each developper will have to redo the same again and again with the corresponding flow of bugs (what if I forget a "break"? Uh oh) and low productivity (not even talking about documentation). Do we agree that this proves the need of a library? The next valid question would be, why MSM? It doesn't have to. If you're happy with Statechart or another library and don't need the speed, it's really ok for me, I promise ;-) MSM is for people who, like me, want a declarative syntax. People who want to have a look at the transition table and see the whole structure of a machine. Not as clearly as on a diagram but better than just code. That's why there is a transition table, and that's why there is eUML, to make it even clearer. This will greatly help us developers communicate with domain experts who will not understand code, but quite fast understand a state machine (I tried an it works). The second reason is the descriptive syntax of MSM. I wanted a library which would help a Model-Driven-Development. I wanted a library allowing us to switch from a graphical model to code and code to model. And I wanted the mapping to be complete. The goal would be to, at some point, never have to edit the code. I don't know how far I'll push it but you can be sure that I will push it as far as I can. This is where the functors added in eUML and the reusable states will help. I hope I managed to answer your question. Christophe

7 7

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

10 Dec '09

Hi Jeff, >I've dragged myself back to 2009 from 2004 where I've been stuck with >CodeWarrior and an emulated OSX 10.3 environment with no chance of using > any modern boost libs. So I hope to have a review in by the end of the week. Great to have you back in 2009! >Indeed MSM 1.x showed g++4.2 much faster and uses less ram than VC8. Is >MSM 2.x any faster or more ram frugal? Sorry about it but probably not. The engine of 2.0 is based on the one of 1.20 with an added (tiny) metaprogramming layer to convert the front-end table to a back-end one. So it could be actually slower. Not much with VC9 but I didn't measure with VC8. This tiny part was enough to lose g++3.4 for good though :( >Unfortunately the same code takes over 2.5 minutes on VC8 >Aah! I should mention these times are for debug builds > This forced me to revert to the TMP book's STT >implementation which compiled in less than 30 seconds on both platforms, >and allows Incredibuild to do it's job. Yes, VC8 is from far the slowest MSM-supporting compiler and debug is the worst, in compile-time and ram usage. I'm afraid, the best I can offer would be a mini-MSM backend based mostly on the book example but supporting basic frontend features so that at least you'll be able to switch the backend if you change compiler one day. I noticed that using precompiled headers will reduce the compile-time by about a third. >Interestingly if I just put all the MSM implementation inline there is >about a 1 minute overall build time improvement. What do you mean with inline? It sounds interesting. >My efforts at submachine refactoring actually increased compile times >significantly. Also my main motivation for using the STT is it's ability >to give both a forest-and-trees presentation of a moderately complex set >of operations. Any refactoring just to get better compile times that >obscures this ease of understanding just negates the benefits. Of course >if refactoring into regions/zones exposes some underlying relations >inherent in these states, transition and operations than it's fully >justified, IMHO. Refactoring into regions is usually a good idea from a design point of view. I didn't mean it as a pure compile-time reduction measure though. I was just describing what, in my experienced, could reduce the compile-time a little. Do you maybe remember what increased your compile-times? >I can attest to Christophe responsiveness and willingness to accommodate >users needs. Thanks! It was a two-way street because MSM greatly gained from your (and others') suggestions. Christophe

1 0

boost_extension
by Christian Henning 10 Dec '09

10 Dec '09

Hi there, to get the boost extension movement going how would people feel if we create a new project on sourceforge called "boost_extension". This will be a placeholder for all extensions to all boost accepted libraries. The goal is to have a project structure very similar to boost. For instance, all extensions have to have tests, documentation, etc supported by bjam. The folder structure will be the same boost, like boost_extension\boost\gil\io or boost_extension\libs\gil\io\test\ There will be a review process as well. Only accepted libraries will be added. Hopefully enough people will be interested in participating. As, for releasing, again we would model after boost. There will be a developing trunk and a release branch. Hopefully within the next couple of releases we can sync releases with boost. I know there is a plethora of issues involving such an effort. Please let me know what you think. Thanks, Christian

6 12

[Integer] Help needed with Codegear failures
by John Maddock 10 Dec '09

10 Dec '09

Boost.Integer now just has failures with the codegear compiler, for example: http://beta.boost.org/development/tests/trunk/developer/output/siliconman-b… These failures have always been present I believe, but weren't previously being fully tested. Anyone any ideas? Thanks, John.

2 2

Updated performance results using Boost Serialization 1.41
by Brian Wood 10 Dec '09

10 Dec '09

I've recently updated the performance section of a comparison between the Boost Serialization library and the C++ Middleware Writer -- http://webEbenezer.net/comparison.html#perf<http://webebenezer.net/comparison.html#perf>. The new tests were done on Fedora 12 and Windows Vista. The previous version of that file is here http://webEbenezer.net/comp138.html#perf<http://webebenezer.net/comp138.html#perf>. The most dramatic change occurred on Windows. Previously the Boost versions were around 2.7 times slower than the Ebenezer versions. Now they are between 3.8 and 4.0 times slower than the Ebenezer versions. I believe that difference is due to our dropping return codes for exceptions. I'm not sure why it shows up more on Windows than on Linux. Cheers, Brian Wood Ebenezer Enterprises http://www.webEbenezer.net "When a man's ways please the L-RD, he makes even his enemies to be at peace with him." Proverbs 16:7

5 10

review request: addition to type_traits library of is_less_comparable<T, U> and others
by Frédéric Bron 09 Dec '09

09 Dec '09

I would like to propose to your review the following addition to the type_traits library (at https://svn.boost.org/trac/boost/browser/sandbox/type_traits and http://dl.free.fr/tK0BwIzYy) The purpose of the addition is to add type traits to detect if types T and U are comparable in the sens of <, <=, >, >=, == or != operators, i.e. if t<u has a sens when t is of type T and u of type U (same for <=, >, >=, ==, !=). The following traits are added: is_equal_to_comparable<T,U> is_greater_comparable<T,U> is_greater_equal_comparable<T,U> is_less_comparable<T,U> is_less_equal_comparable<T,U> is_not_equal_to_comparable<T,U> The names are based on the corresponding names of the standard template library (<functional> header, section 20.3.3 of the standard). The code has the following properties: * returns true if t<u is meaningful and returns a value convertible to bool * returns false if t<u is meaningless. * fails with compile time error if t<u is meaningful and returns void (a possibility to avoid compile time error would be to return true with an operator, trick but this has little sens as returning false would be better) The compilation has been tested with g++ 4.3.2 and icpc 10.0 on linux 64 bits, g++ 3.4.4 on cygwin, mingw32 3.4.4 on cygwin. Regards, Frédéric

15 54

[msm] New eUML syntax
by Christophe Henry 09 Dec '09

09 Dec '09

Hi, As it seems that the eUML syntax suggested by Robert Stewart is favored by most of those who gave their opinion about it, I decided to give it a try and uploaded into the vault (http://www.boostpro.com/vault/index.php?direction=0&order=&directory=Msm&) a preview version (review_tests.zip) of the new syntax, along with 3 tutorials rewritten using this new syntax. This will allow us to play with it and see if we like it. I'd be happy to get some feedback. I personally found it hard to get used to this syntax, but it can be because I'm so used to the "old" one. Another effect is that I had to reorganize my transitions based on the target state instead of the source, which made me change my debug state_name array (as written in Annex A, the index of a state is based on its position in the transition table). If you don't use state names as debug information, you needn't mind about it. Tested compilers were VC9 and g++ 4.3. Please post your comments in the developer list. Have fun! Christophe PS: a few speed optimizations (due to interesting tests from Barend Gehrels) are also in, so should the back-end make any problem, please let me know.

2 1