Re: [Boost-users] [statechart] Can events carry data?

From: BRIDGES Dick (Dick.Bridges_at_[hidden])
Date: 2005-09-14 12:04:57

Sorry about the delay - got sidetracked by work. ;)

Your clarifications were a great help.  Many thanks for the library
*AND* the help!

Regards,
Dick

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] 
> [mailto:boost-users-bounces_at_[hidden]] On Behalf Of 
> Andreas Huber
> Sent: Wednesday, August 31, 2005 2:57 PM
> To: boost-users_at_[hidden]
> Subject: Re: [Boost-users] [statechart] Can events carry data?
> 
> 
> BRIDGES Dick wrote:
> > I'm still not clear on the requirements surrounding such an
> > instance.  For example, the reference requires that
> > <code>new E(*pCE)</code> be well-formed and make "a copy of
> > pE".
> 
> Maybe I should have described that differently. That row in the table 
> translates as follows:
> 1. event<> subtypes must have a publicly accessible copy constructor 
> (compiler-generated or not)
> 2. If overloaded, operator new must be publicly accessible
> 
> Since the library only requires the quoted expressions be 
> well-formed, 
> it is up to you to define the semantics of the copying. What the 
> copy-ctor actually does is of no concern to the library.
> 
> > Does the current implementation work ok with
> > boost::shared_ptr?
> 
> I assume you mean shared_ptr<> instances as members of 
> events? I don't 
> see any problems here.
> 
> >  How about auto_ptr?
> 
> That should work if you define a copy-ctor that transfers 
> ownership to 
> the copy.
> 
> > If a data member
> > would normally require a deep copy, would I be better off
> > managing it external to the event object
> 
> I'm not sure I understand the question. I don't see how you 
> would manage 
> that data-member externally; you don't mean a global 
> variable, do you? 
> Also, are we talking about a single-threaded or an MT system?
> 
> > - or avoiding that
> > type of data altogether?  How many copies are we talking
> > about here?
> 
> Events that the user allocates with new are never copied. 
> Stack-allocated events are copied exactly once only if they are 
> deferred. See Step 8 here:
> 
> http://boost-sandbox.sourceforge.net/libs/statechart/doc/refer
ence.html#process_event

> Any cautions and/or advise regarding the use of data members
> in events would be appreciated.

The library does not introduce problems that wouldn't exist otherwise. 
In an ST system everything should "just work" without you spending any 
thought on copying, other than that a reaction might be working with the

original *or* the copy of the event. In an MT system the usual 
precautions against race-conditions, deadlocks, etc. apply. If it is too

costly to deep-copy everything in the event, you must ensure that 
multiple threads accessing the shared part are appropriately locking 
mutexes, etc.

HTH,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header. 
_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users