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#proc...
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.