Boost logo

Boost Users :

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. 

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net