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

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-08-31 16:56:46

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/reference.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.