- Boost - lists.boost.org

Re: [boost] [msm] Nested submachines and explicit state entry
by Christophe Henry 10 Jun '10

10 Jun '10

>MSM Documentation (section: Explicit Entry): >--------------------------------------------- >You can then use it as target in a transition with State1 as source: >_row < State1, Event2, SubFsm2::direct< SubFsm2_::SubState2> > >The syntax deserves some explanation. SubFsm2_ is a front end. SubState2 >is a nested state, therefore the SubFsm2_::SubState2 syntax. The >containing machine (containing State1 and SubFsm2) refers to the backend >instance (SubFsm2). SubFsm2::direct states that an explicit entry is >desired. --------------------------------------------- >So I think the code snippet has to look like as follows (SubFsm2 instead >of SubFsm2_): >_row < State1, Event2, SubFsm2::direct< SubFsm2::SubState2> > Actually not but I might need to detail a bit. Consider: struct SubFsm2_ ... // front-end { struct SubState2 ... // ---> nested type }; typedef msm::back::state_machine<SubFsm2_> SubFsm2; //back-end SubFsm2_ : front-end SubFsm2: back-end SubFsm2_::SubState2 : the complete name of SubState2. Which means that : _row < State1, Event2, SubFsm2::direct< SubFsm2_::SubState2> > is correct. The back-end(SubFsm2) provides a direct entry type (SubFsm2::direct<>) taking as argument the direct entry state, which name is SubFsm2_::SubState2. Regards, Christophe

1 0

[msm] Choosing initial event in sub machines
by Christophe Henry 10 Jun '10

10 Jun '10

>>> Actually, this is exactly the behaviour what we want >> I'm not sure I get. You'd want the submachine to use its own initial >> event and receive this one instead of the containing machine's? It's >> probably possible but I'm wondering what could be a use case for this. >> Could you please elaborate? >No, sorry for the confusion. The implemented msm behaviour is the one we >want. >So there is no need for a change in the msm code ;). Good because my todo list is getting quite long ;-) >Maybe it would be good to describe it in the documentation. Will be done. Regards, Christophe

1 0

Re: [boost] [endian] endian flip and endian domain
by Dave Handley 10 Jun '10

10 Jun '10

Robert Stewart wrote: > Dave Handley wrote: > > Gottlob Frege wrote: > > > > > I think what I am saying is that, conceptually at least, the > > > endian-types come first, and the straight functions are built on top > > > of that (instead of the other way around as most are suggested). > > > Now, I wouldn't want that to impact performance, which is why I say > > > 'conceptually'. We can specialize the heck out of > > > everything so that > > > performance wins, but I think the conceptual foundation is > > > important. > > > > I disagree. If you have an endian type then I think you are > > coding in from the beginning a need for a copy in order to > > endian swap - even if the endian swap is a no-operation. > > This discussion isn't necessarily intended to account for swap in place, > which all have agreed is necessary. Rather, I at least am > thinking of this discussion as applying to the object-based approach > and to the copy-based conversion functions. The problem is with the initial statement above which says "the endian-types come first, and the straight functions are built on top of that". This is what I fundamentally disagree with. IMHO, you have to write the straight functions (in Tom's terminology, swap and swap_in_place), then implement the endian-types on top of that interface. If you do it the other way around you enforce a copy on the function based interface. At least as far as I can see. I don't disagree that many people want and might well heavily use an object-based interface. Robert Stewart wrote: > > Next, on naming, I think we should be very careful that we > > don't over-think the naming question. I'll ask a general > > question. What term does everyone use when talking about > > endian swapping? Certainly in my programming career I've > > never heard it called anything other than endian swapping. > > Also (and I know this shouldn't be taken as a definitive > > source) Wikipedia refers to the process of changing > > endianness as a byte swap. Shouldn't we use swap because > > that is what everyone knows the process of changing > > endianness as? That's my 2d, but I'm not wholly against > > another naming option. > > While I sympathize with your position, it has been noted that "swap" > is a very bad choice because of std::swap(), boost::swap(), etc. > Those functions have a distinct behavior and purpose that endianness > conversion does not satisfy. Considering that our work could be > standardized in the future, can you imagine the committee > accepting "swap" as the name? I can't. That implies the need to > find another name. I agree that the existence of std::swap() is an issue. In that context I would argue for something more like boost::endian_swap. I think changing the verb used is an obfuscation and not necessarily helpful. Dave

4 5

: Review of a safer memory management approach for C++
by Bartlett, Roscoe A 10 Jun '10

10 Jun '10

A few responses ... > 4. Re: Review of a safer memory management approach for C++ > (Mathias Gaunard) > 5. Re: Review of a safer memory management approach for C++ > (Roland Bock) > 6. Re: Review of a safer memory management approach for C++ > (Fernando Cacciola) > ------------------------------ > > Message: 4 > Date: Mon, 07 Jun 2010 18:07:55 +0100 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++ > Message-ID: <huj91v$cem$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Bartlett, Roscoe A wrote: > > > Tools like valgrind and purify are very helpful but are not nearly > sufficient as described in Section 3.2 (and other sections) in: > > > > http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf > > The limitations you give are simply that you expect valgrind to do more > than tell you about memory errors, but also to tell you about contract > violation of any library as well. > That's not something a generic tool can do. [Bartlett, Roscoe A] Exactly my point. > Contracts are specified by > each library, and can be optionally checked in a special debug mode the > library may provide. [Bartlett, Roscoe A] Exactly. However, rather than doing this haphazardly why not have a consistent built-in approach in your own software to catch such mistakes automatically in a debug-mode build? Enter the Teuchos MM classes and the idioms described in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf > All that valgrind can do (as far as I my usage goes) is tell you if you > access some unallocated memory (relatively to the default global > allocator) or if you read an uninitialized object. [Bartlett, Roscoe A] Valgrind and purify are very useful but they will often only flag there is a problem until much after the original error occurred. As an example, a few months ago I was using std::multimap for the first time in a GCC implementation. The documentation I found for std::multimap on the web was not very detailed and did not really explain behavior in a few important cases (I have had a hard time finding decent standard C++ library documentation). I ran the code and it behaved in strange ways, segfaulted, etc. I turned on the checked STL implementation with -D_GLIBCXX_DEBUG but it did not complain about anything. I ran valgrind on it is it complained there was a problem in a place in the code that made no sense at all. I knew the only "unsafe" code that I had written (that did not exclusively use the Teuchos MM classes and idioms) was the std::multimap code. After more experimentation I figured out that I had guess the behavior of std::multimap incorrectly. Once I figured out what the behavior really was, the program ran fine. Here was a case where the checked STL implementation was not catching a basic user error and valgrind was worthless. I just wish that I would have saved the state of this code in a branch or something so that I could show this to other people. > ------------------------------ > > Message: 5 > Date: Mon, 07 Jun 2010 19:14:33 +0200 > From: Roland Bock <rbock(a)eudoxos.de> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++ > Message-ID: <4C0D28F9.1060301(a)eudoxos.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Bartlett, Roscoe A wrote: > > Come one, at least some people on this mail list must have had > similar nightmare experiences in trying to track down and diagnose hard > memory misuse errors in C++ that took days of effort to resolve (even > with the help of tools like valgrind and purify). > > > > Hi, > > yes, I had such experiences, but that's years in the past, when I did > not know shared pointers. With shared pointers only very few memory > issues ever occurred. [Bartlett, Roscoe A] I have to admit, that w.r.t. single objects, after I started using smart reference-counted pointers, I experienced very few memory errors. However, I was still having some errors and I was writing a lot of paranoid manual error checking code with all of the raw pointers that remained (and yes, if all you have is an RCP class, you will still need to use raw pointers in many cases). After I developed Teuchos::Ptr, the raw pointers to single objects went away and I ripped out a bunch of manual error checking code (a process that I will likely never finish because of the large amount of code I have written over the years). There are people in my domain that still today will refuse to use a smart pointer class and insist on manipulating raw memory, even in brand-new code. The cycle of undefined behavior, segfault, etc. will continue ... > These days, our memory issues are of a different kind: Memory > fragmenation due to malloc's strategies in multithreading scenarios. > These are even worse, because formally, there is no problem in the > code. > Writing you own allocator and then suddenly not being able to use > valgrind anymore, that's the memory fun today. [Bartlett, Roscoe A] Do people have experience with library allocators from MPI and TBB? These are supposed to place memory more carefully but they mean that you can't use the allocator embedded in std::vector anymore. > ------------------------------ > > Message: 6 > Date: Mon, 07 Jun 2010 14:32:15 -0300 > From: Fernando Cacciola <fernando.cacciola(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++ > Message-ID: <hujad9$ic7$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Bartlett, > > Just for the record and since your statements below are about general > experiences with large scale C++ projects, let me put my own > experiences in > context: I had been architecting, designing and implementing large- > scaled > projects from the early 90's. The largest of which accounts for 160K > of C++ > code, which in fact I wrote almost entirely myslef. > Again this is just to put the comments based on my experience in > persective. [Bartlett, Roscoe A] The real problem comes when you can't architect all of the code yourself with one consistent style and instead have to glue together code from lots of different sources that had very inconsistent ideas about design and managing memory. Early experience with this type of work lead me to put in the extra_data hack in Teuchos::RCP. It was not pretty but it worked to glue all kinds of software together effectively. > > These types of experiences have > > lead many C++ teams to code C++ with a (justified but unfortunate) > paranoia > > about the use of memory in C++ that has all kinds of bad consequences > > I think that those memory problems are funtamentally rooted at a design > issue. [Bartlett, Roscoe A] The problems are rooted in the raw manipulation of memory with raw pointers and raw calls to new and delete and raw use of arrays as raw pointers. In my opinion that this is the design problem. Others will likely disagree. > In the mid 90's I used to developed best practices and utilities for > sane memory > management (and other sanity requirements), in the same spirit of the > paper you > presented (I did read it btw). I even implemented custom allocators, > based on > class-specific memory pools, and mandated that every object should obey > a strict > allocation-deallocation protocol. > > Simply defining a new class on my system required the use of a macro- > based DSL, > something like "DEFINE_DERIVED_OBJECT(Foo,Base). Likewise, object > graphs had to > be very carefully spelled with my DSL, as in "INCLUDE_SUBOBJECT(Bar)", > and so on.. > > This forced everyone in the team, year after year, to learn a language > on top of > C++. [Bartlett, Roscoe A] Note that the STL absolutely defined a new language in C++ as has been pointed out by Scott Meyers in Item 1 in "Effective C++ 3rd edition". The question is if the new language provides enough benefit to justify having to learn it. I believe that STL has been hugely worth it but it is only a container, algorithm, and data-structure library and does not solve the most fundamental problems with C++ coding; the usage of raw pointers which the STL alone did not eliminate the need for in many programs (others may disagree). > In the long end, however, I realized I was just overengineering the > problem way > too much, putting a big burden on the team and making it difficult for > newcomers. [Bartlett, Roscoe A] That was my opinion also in the late 90s as I was also going down that road and I stopped around 1999 but I have since come to regret that view today for the reasons described in Section 3.2 of: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf As argued in Sections 5.8 and 6.2 of the above document, the Teuchos MM classes and the associated idioms create a fairly thin language above raw pointers that increase the self-documenting nature of the code in a way you can't do with a language like Java or Python. > When C++ evolved I found new, much simpler ways to solve the same > problems, and > in particular, memory problems: using smart pointers (even long before > boost::shared_ptr came alone). Once I started using smart pointers I > never > looked back, and I never again, ever, had to spend a single minute on a > memory leak. [Bartlett, Roscoe A] Smart pointers solve leaks very well but the real problem are other invalid usages of memory that create undefined behavior. In CSE we have to use lots of arrays and we can't mandate that all memory use std::vector or STL allocators to do all of the allocations. The main holes that were filled with the Teuchos MM classes were better safer handling of arrays without mandating (not even at compile-time) how the memory is allocated or deallocated in a consistent system. > > Come one, at least some people on this mail list must have had > similar > > nightmare experiences in trying to track down and diagnose hard > memory misuse > > errors in C++ that took days of effort to resolve (even with the help > of > > tools like valgrind and purify). > > > Before I started using smart pointers, yes. > After that, no.. never again. [Bartlett, Roscoe A] Yes but what currently exists in C++0x and boost for arrays is not sufficient to provide the guarantees. Read the paper, look the classes, and make of you mind for yourself. Also, what did you do in cases where you did not need machinery for persisting associations and could not afford the overhead of reference-counting classes? Did you just use a raw pointer? Did you use a raw C++ reference? Are all of your objects using value semantics (deep or shallow copy) and just copied objects? That was the hole the Teuchos::Ptr class was designed to fill and it still provides full referentially checking in a debug-mode build. > > And again, tools like valgrind and purify will *never* catch semantic > misuse > > of memory (i.e. allocating a big chunk of memory and then breaking it > up to > > be used to construct different objects and array of objects). The > Teuchos MM > > classes will catch most semantic misuse of memory in a way that no > tool like > > valgrind and purify every can (because they don't know the context of > your > > program, they only know that any read/writes in a big block of memory > that > > you allocated look okay). I think this is a big deal in catching > > hard-to-find defects that are not (technically speaking) memory > misuse > > defects but are program defects none the less. > > > I totally fail to see why this design mistakes (wrong allocation > pattern) should > be detected by a framework? These are design issues and should be deal > with at > that stage. Surely any team can be trained not to make such mistakes. [Bartlett, Roscoe A] Telling people to simply stop making mistakes is not a solution to every problem. W. Edwards Deming stated that most mistakes that are made by people are due to a faulty process or faulty support tools. If people keep making mistakes then we need to first look at the processes and tools and not just blame them. We should be able to create the tools so that basic errors in memory usage are automatically detected, even in C++. The Teuchos MM classes and idioms paired with a static analysis tool (if we could find and configure one) to help enforce the idioms would largely solve this problem in C++. Otherwise, most people what currently write CSE software would be better off writing code in a language like C# but that is just not viable for many reasons.

5 6

Re: [boost] [msm] Nested submachines and explicit state entry
by Michael.Herchel＠rohde-schwarz.com 10 Jun '10

10 Jun '10

Hi Christophe, >>> There are several reasons to this and it took me a while to figure out >>> what was happening. >>> The first one is that there are 2 errors in the example: >>> RunningStateMachine::Inner1::direct<RunningStateMachine_::Inner1_> should be: >>> RunningStateMachine::direct<RunningStateMachine_::Inner1> >>> >>> As you are directly entering RunningStateMachine, not Inner1. >> >>actually I have made 2 mistakes :). One above the second is that I used Inner1_ >>which is a frontend instead of Inner1 caused that the on initial transition >>is getting triggered after entry of Inner1 >Ah yes I forgot that I corrected that one too. Could you please also correct the documentation regarding explicit entry. In the documentation you explicitly say that you have to pass the front end, which is wrong according to you. MSM Documentation (section: Explicit Entry): --------------------------------------------- You can then use it as target in a transition with State1 as source: _row < State1, Event2, SubFsm2::direct< SubFsm2_::SubState2> > The syntax deserves some explanation. SubFsm2_ is a front end. SubState2 is a nested state, therefore the SubFsm2_::SubState2 syntax. The containing machine (containing State1 and SubFsm2) refers to the backend instance (SubFsm2). SubFsm2::direct states that an explicit entry is desired. --------------------------------------------- So I think the code snippet has to look like as follows (SubFsm2 instead of SubFsm2_): _row < State1, Event2, SubFsm2::direct< SubFsm2::SubState2> > Regards, Michael

1 0

[msm] Choosing initial event in sub machines
by Michael.Herchel＠rohde-schwarz.com 10 Jun '10

10 Jun '10

Hi Christophe, >> Actually, this is exactly the behaviour what we want > I'm not sure I get. You'd want the submachine to use its own initial > event and receive this one instead of the containing machine's? It's > probably possible but I'm wondering what could be a use case for this. > Could you please elaborate? No, sorry for the confusion. The implemented msm behaviour is the one we want. So there is no need for a change in the msm code ;). Maybe it would be good to describe it in the documentation. Regards, Michael

1 0

Re: [boost] [msm] Nested submachines and explicit state entry
by Christophe Henry 10 Jun '10

10 Jun '10

>> There are several reasons to this and it took me a while to figure out >> what was happening. >> The first one is that there are 2 errors in the example: >> RunningStateMachine::Inner1::direct<RunningStateMachine_::Inner1_> should be: >> RunningStateMachine::direct<RunningStateMachine_::Inner1> >> >> As you are directly entering RunningStateMachine, not Inner1. > >actually I have made 2 mistakes :). One above the second is that I used Inner1_ >which is a frontend instead of Inner1 caused that the on initial transition >is getting triggered after entry of Inner1 Ah yes I forgot that I corrected that one too. >I found it even strange that it compiles when the frontend of and >inner state machine is used in the outer state machine transition >table. This surprises me a little because I tried with g++ 4.4 to replace in the corrected example Inner1 by Inner1_ in SM1's table and the compiler correctly complained. What did you do?

2 1

[msm] Choosing initial event in sub machines
by Christophe Henry 09 Jun '10

09 Jun '10

Hi Michael, > I just came along another question regarding state machines and sub > machines. > > With "typedef my_initial_event initial_event" it is possible to customize > the initial event. > This does not work for nested sub machines, because in those cases msm > just forwards the event that triggered the state change so that we end up > in the sub machines initial state. > Msm does not use the specified initial event of the sub machine to trigger > the initial state of the sub machine. Correct. This is actually the wanted behavior to respect the Liskov substitutability principle. It would be confusing if you replaced a substate by a submachine and get a different entry behavior. This means that the containing machine's initial event will get propagated to any substate or submachine marked as the initial. > Actually, this is exactly the behaviour what we want I'm not sure I get. You'd want the submachine to use its own initial event and receive this one instead of the containing machine's? It's probably possible but I'm wondering what could be a use case for this. Could you please elaborate? >but is it UML conform? > Do you have any idea? Neither is actually ;-) UML does not define the notion of an initial event. It was added into msm to allow a unique interface for entry behaviors (instead of one for "normal" entries and one for entry through an initial pseudo-state. All what UML defines is an initial pseudo-state which can have only one outgoing transition to a real state (making it the initial state). This cannot even be a real transition, it can have no event and no guard, only an action. So, as UML has no initial event and it is purely a msm construct, we are free to define it as we wish. I suppose we could allow the submachine to override the default behavior, but I would need to see at least one compelling use case before I punish compilers with some more metaprogramming ;-) Regards, Christophe

1 0

[serialization] Boost.DateTime tests failing
by Andrey Semashev 09 Jun '10

09 Jun '10

I see that a few tests of Boost.DateTime (see [1] for instance) are failing because Boost.Serialization fails to complile. It seems like revision 62546 caused this. Robert, will you take a look at it? [1] <http://www.boost.org/development/tests/trunk/developer/Sandia-darwin-4-0-1-…>

2 1

Re: [boost] [fusion] conflict with mpl
by Christophe Henry 09 Jun '10

09 Jun '10

>> Hi, >> >> While looking at the trunk test results for MSM, I realized (with a >> shock) that many test cases were not working with g++ any more. The >> reason is listed in (read the last few lines): >> http://www.boost.org/development/tests/trunk/developer/output/minion-clang-… >> >> It appears there is a conflict between mpl and fusion for at. >> Editing boost/fusion/container/set/detail/deref_impl.hpp from >> return at<typename It::index>(it.seq->get_data()); >> >> to >> return ::boost::fusion::at<typename It::index>(it.seq->get_data()); >> >> Seems to solve the problem in the small example I attached. >> >> This stuff is pretty urgent for me because it breaks a lot of msm tests. >> How to proceed? The Monday deadline is looming ;-) > > Feel free to check in the fix, Christophe. Thanks! I just did.

1 0