- Boost - lists.boost.org

[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