- Boost - lists.preview.boost.org

[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

stuck with template programming
by DE 09 Dec '09

09 Dec '09

hi everyone i managed to write piece of code which seems to be valid c++ but compiles neither with msvc80 nor with icc11 the code is in the attachment if this question falls out of this maillist' scope please tell me where can i post it any ideas how to work around these problems? -- Pavel

2 1

[integer]/cstdint.hpp How to use portable literals?
by vicente.botet 09 Dec '09

09 Dec '09

Hi, I need to use boost::intmax_t literals in a portable way. I remember some discussion related to this subject, but I've not found the thread. Could someone point me to these threads, or tell me how I can achieve this. I'm currently using the macro INTMAX_C, but it seems that this macro is not always defined. Thanks, _____________________ Vicente Juan Botet Escribá

1 0

[property-map] Generalizing identity_property_map for arbitrary types
by Belcourt, Kenneth 09 Dec '09

09 Dec '09

Hi, I've found the property map library to be very useful and would like to propose a minor enhancement to permit the identity_property_map to work for arbitrary types. The reason for this is that some computationally intensive algorithms suffer noticeable performance degradation when I convert them to generic algorithms using property maps. Having a typed identity property map that returns, for example, the double passed into it significantly speeds up our algorithms, at least for those fields that are not mutable. I've attached a patch, and could supply a motivating example, if anyone is interested. -- Noel

2 3

Blog and source code for "abstract_fsm"
by David Bergman 09 Dec '09

09 Dec '09

As I mentioned elsewhere, I created an abstract FSM interface for non-complex FSM's, translating to either Statechart or MSM in compile-time. There is a blog basically repeating what I posted earlier here at http://blog.davber.com/2009/12/08/abstract_fsm-finite-state-machines-in-c/ and the source code is found at http://github.com/davber/abstract_fsm. Hmm, I always have a hard time deciding which place should be the canonical one - with examples and such - the Github repository or the blog (post)! If somebody can tell what is Right and Wrong here, I would appreciate it ;-) /David

1 0

[mpl] [type_traits] [enable_if] Overloading Problem with GCC 3.3.3
by Stewart, Robert 08 Dec '09

08 Dec '09

Can anyone figure out why GCC 3.3.3 doesn't like the following member function overloads? VC7/8/9 and GCC 4.1.2 have no problems with this code. #include <boost/mpl/and.hpp> #include <boost/mpl/not.hpp> #include <boost/type_traits/is_const.hpp> #include <boost/type_traits/is_convertible.hpp> #include <boost/utility/enable_if.hpp> struct Bar { }; template <class T> struct Baz { }; struct Foo { template <class T> typename boost::enable_if < boost::mpl::and_ < boost::is_convertible<T,Bar> , boost::mpl::not_<boost::is_const<T> > > >::type set(Baz<T> const & _value); template <class T> typename boost::enable_if < boost::mpl::and_ < boost::is_convertible<T,Bar> , boost::is_const<T> > >::type set(Baz<T> const &); }; GCC 3.3.3's error message is: error: `template<class T> typename boost::enable_if<boost::mpl::and_<boost::is_convertible<T, Bar>, boost::is_const<T>, mpl_::bool_<true>, mpl_::bool_<true>, mpl_::bool_<true> >, void>::type Foo::set(const Baz<T>&)' and `template<class T> typename boost::enable_if<boost::mpl::and_<boost::is_convertible<T, Bar>, boost::mpl::not_<boost::is_const<T> >, mpl_::bool_<true>, mpl_::bool_<true>, mpl_::bool_<true> >, void>::type Foo::set(const Baz<T>&)' cannot be overloaded _____ Rob Stewart robert.stewart(a)sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 2

New libraries deadline approaching
by Vladimir Prus 08 Dec '09

08 Dec '09

Boosters, the deadline for merge of new libraries to 1.42 is Dec 14. So far, the only library that was added to trunk relative to 1.41 is uuid. Andy, does it seem like merge to release branch is possible by Dec 14? Do you need any assistance? It seems that you have succeeded in integrating the tests into the regression framework. However, one test -- test_generators, appear to fail on all platforms and test_uuid fails on a bunch as well. If the test failures are unclear, you might want to ask platform experts for help, while there is time. The next deadline will be Jan 4, when the release branch will be closed for major code changes. -- The Release Managers, Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

5 7

[interval containers (itl)] Update on Review Version. Element iterators added.
by Joachim Faulhaber 08 Dec '09

08 Dec '09

Dear all, while hanging around in "The Queue" my library was getting pretty bored :-/ So I decided to implement some depreciated featured to arrange for some entertainment =) Well, jokes aside, for a long time I resisted to implement iteration on *elements* for interval containers. Element iterators would be an invitation to inefficient usage of interval containers just by normal habitual use of iterators. For instantiations with continuous domain types like interval_set<double>, interval_set<rational<int>>, interval_set<string>, etc. element iteration would not be possible at all. Yet the questions about such iteration and the related question of interval containers being a model of SortedAssociativeContainer reoccurred in many feed backs on presentations of my library. There even was a proposal for a DenseSet library by Vicente Botet in the wiki's Library Wish List: https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction that follows the idea of interval containers but provides element iteration in order to fully implement SortedAssociativeContainer. So finally I decided to provide element iteration and put the responsibility to avoid inefficient deployment on the user. Moreover, while element iteration on interval containers can be substituted easily by simple loops, the element iteration over an interval_bitset that Zachary Turner asked for http://archives.free.net.ph/message/20091103.064651.263bf6bb.en.html is not so trivial, so it can not be substituted easily by a few lines of user code. That gave me some new motivation. So I have uploaded an update of my library's review version http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_3_… to the vault that is extended by these features: * element iterators on all interval containers http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/fu… * itl::insert_iterator and itl::inserter that allows interval containers to be copied or transformed from std::containers using insert semantics http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/ex… * itl::add_iterator and itl::adder that allows interval containers to be copied or transformed from std::containers using addition semantics so that aggregate on overlap can be done. http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/ex… In the extended library itl_xt that is part of http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_pl… * there is an implementation of a large interval_bitset, that combines interval compression and bit compression. Element iteration is now available for interval_bitset. https://svn.boost.org/svn/boost/sandbox/itl/boost/itl_xt/interval_bitset.hpp Element iteration now enables interval_containers to be used with std::algorithms like the corresponding containers of elements. The major requirement for usability of element iteration is that the interval container's domain_type is a discrete type that has a smallest steppable unit and exposes an increment and decrement operator for it's in- and decrementation. I have successfully tested copy (and variants), equal, lexicogrphic_compare, find, lower_bound, upper_bound, includes and set_<algorithms>. All tested algorithms that were applicable to a SortedAssociativeContainer of elements were also working with interval_containers using element_iterators. The test have been done using a law "AtomicEquivalence" https://svn.boost.org/svn/boost/sandbox/itl/boost/validate/laws/atomic_equi… on the law based test automaton (LaBatea) https://svn.boost.org/svn/boost/sandbox/itl/libs/validate/example/labat_sor… https://svn.boost.org/svn/boost/sandbox/itl/libs/validate/example/labat_sor… https://svn.boost.org/svn/boost/sandbox/itl/libs/validate/example/labat_sor… https://svn.boost.org/svn/boost/sandbox/itl/libs/validate/example/labat_sor… https://svn.boost.org/svn/boost/sandbox/itl/libs/validate/example/labat_sor… https://svn.boost.org/svn/boost/sandbox/itl/libs/validate/example/labat_sor… So I think this is a valuable addition to interval containers in the end and I hope it'll make std::algorithm aficionados among you happy ;-) Cheers Joachim ----------------------------------------------------------- Some repeated information on the library: Please note that the original ITL as presented in May 2008 has been split into 3 parts and only the *first* part was submitted for review (2009-09-18): itl : Core library, interval containers, SUBMITTED FOR REVIEW Additional parts are: itl_xt : Extensions like interval_bitset, histories and generalized crosstables validate: The law based test automaton (LaBatea). A validation tool using laws aka axioms. *itl* is a complete library containing all required ingredients particularly a separate test suite (NOT using LaBatea) and the quickbook documentation. The code is successfully compiled and tested with gcc-3.4.4, 4.1.0, 4.3.2 and msvc-8.0, 9.0, 10.0. I have uploaded the first update of the review version as itl_3_2_0.zip to the vault in section containers. http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_3_… Another file itl_plus_3_2_0.zip contains all three parts (itl, itl_xt and validate). http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_pl… Reviewers interested in the law based testing part may have to refer to this file to examine those tests. The law base testing examples compile and run with gcc-4.3.2, msvc-8.0, 9.0 and 10.0. LaBatea does not compile with gcc-4.1.0 or older. The quickbook generated documentation is included in the zip files and is also available online at http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html Sources are also available form the sandbox: https://svn.boost.org/svn/boost/sandbox/itl/

1 0

[type_traits] Need help with an - unfixable? - issue
by John Maddock 08 Dec '09

08 Dec '09

This issue just came in: https://svn.boost.org/trac/boost/ticket/3730 Reduced to the test case below, and I can't see a way to fix this at present, anyone any bright ideas? Thanks, John. #include <map> #include <iostream> #include <boost/type_traits.hpp> class base { public: base() : i(0) {} base(int i) : i(i) { m[i] = "text"; } virtual void method1() = 0; virtual ~base() {}; private: int i; std::map<int, std::string> m; }; class derived1 : virtual public base { public: }; class derived2 : virtual public base { public: }; class intermediate : public derived1, public derived2 { public: intermediate() {} intermediate(int i) : base(i) {} void method1(); }; void intermediate::method1() { } class final : public intermediate { public: final() {} final(int i) : base(i) {} }; // // This class demonstrates what we need to make work inside is_virtual_base_of. // MSVC compiles this just fine (likewise is_virtual_base_of), and only complains // when attempting to use method1. Other compilers (GCC, Intel on Linux) complain // as soon as X is declared, likewise when instantiating is_virtual_base_of. // struct X : final, virtual intermediate { X(); X(const X&); X& operator=(const X&); ~X()throw(); }; int main( int /* argc */, char* /* argv */[] ) { X x; x.method1(); boost::is_virtual_base_of<intermediate, final>::type t; return t.value != true; }

2 1

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

08 Dec '09

Hi Michael, hi Robert, hi Felipe, >CurrentState() + cool_event() >[VeeeeeryLoooooooooongGuard()] >/(LooooooooooooooooongAction()) = DestState() I just wanted to bring an example from SimpleTimer (see doc): Ringing() + tick() == Ringing() [ Source_<m_ringing_cpt>() - Event_<m_tick>() > Int_<0>() ] / (Source_<m_ringing_cpt>() -= Event_<m_tick>() ) would become: Ringing() + tick() [ Source_<m_ringing_cpt>() - Event_<m_tick>() > Int_<0>() ] / (Source_<m_ringing_cpt>() -= Event_<m_tick>() ) == Ringing() Here, it is becoming hard to write action and target state on the same line. And the action can be as big as one wishes. >Here's another suggestion, though it breaks from the logical UML ordering Michael posted previously: >DestState() = CurrentState() + cool_event()[guard()]/(action()) I like this one quite much! Not UML at all but pretty much C++-style. And it'd become easy to write guard and action on the next lines if needed. >CurrentState() + cool_event()[guard()]/(action()) -> DestState() It's very similar with Michael's syntax but I think the operator precedence can be hard to master and we'll need extra parentheses. I think there is no operator -> in proto but ->* . We are making progress :) Christophe

2 1

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

08 Dec '09

>FYI, this is an issue of -- apparently -- English not being Christophe's first language. >Darryl's construct, "This is unlike StateChart, where the idea of object instantiation as state is genuinely useful sometimes,..." >means "MSM's approach is unlike that of StateChart, because StateChart instantiates state objects, which is sometimes genuinely useful." > >I think there was more to the original sentence, which I haven't taken the trouble to recover from earlier posts, >which better developed what Darryl liked about MSM's own approach. >There was, however, no implication that MSM fails to meet expectations because it wasn't like StateChart in this behavior. > >For those for whom English is a second language, I apologize. >Few native English speakers learn the language well. We thus make our inherently complex language harder >still to understand by our mistakes of grammar, syntax, structure, and even word usage. >Add to that the many idiomatic constructs and expressions, not to mention colloquialisms, >we use that it's amazing that you manage to converse with us so well. Oh I see. Sorry Darryl for misunderstanding your post. Robert, thanks for your help! Christophe

1 0