Re: [Boost-users] [statechart] Can events carry data?
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Peter Petrov Sent: Tuesday, August 30, 2005 1:13 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [statechart] Can events carry data?
BRIDGES Dick wrote:
Is there any provision for "event-local" storage? I'd like to create events that carry data (e.g., timestamp, source, etc.) to be used by reactions and transitions to update state-local storage.
I didn't see anything like this in the documentation. Bad idea? Major drawbacks? If it wouldn't be a problem, how might I go about doing it?
struct MyEvent : public boost::statechart::event<MyEvent> { int myData; double myOtherData; MyClass myOtherOtherData; };
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Thank you for the example. 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". Does the current implementation work ok with boost::shared_ptr? How about auto_ptr? If a data member would normally require a deep copy, would I be better off managing it external to the event object - or avoiding that type of data altogether? How many copies are we talking about here? Any cautions and/or advise regarding the use of data members in events would be appreciated. Thanks again for the response. Regards, Dick Bridges
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.
Andreas Huber wrote:
Events that the user allocates with new are never copied.
That's inaccurate. The library does not detect heap-allocation directly. It only detects whether a boost::intrusive_ptr is currently pointing to the event object. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (2)
-
Andreas Huber -
BRIDGES Dick