2 Sep
2011
2 Sep
'11
1:50 p.m.
On Fri, Sep 2, 2011 at 6:04 AM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Thu, Sep 01, 2011 at 03:54:03PM -0400, Paul Davis
wrote:
i'm pretty confused by what you've written here. i use functors which
have copy semantics, and the "event" classes that contain a functor do
not contain a pointer to a functor, but a functor that is copied. this
is the base class:
struct BaseRequestObject {
RequestType type;
bool valid;
InvalidationRecord* invalidation;
boost::function<void()> the_slot;
BaseRequestObject() : valid (true), invalidation (0) {}
};
the "type" member is still there, but differentiates between requests
that require use of the functor ("the_slot") and those that are just
an enum that can be handled with no data (e.g. telling an event
loop/thread to quit).
On Thu, Sep 1, 2011 at 2:37 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
Yes, but
1. I find functor syntax extremely clumsy, involving the creation of
a specific derived functor class (from a template class) for each
one you need.
2. AFAIK (using the terminology of <http://www.newty.de/fpt/functor.html>,
you can't have a TSpecificFunctor member in the event class and
initialise it, it has to be a TSpecificFunctor*. Which in turn
means that at the sender side you either have instances of all
possibly required functor classes available and assign the
TSpecificFunctor* in the event from one of them, or you have to
use new() to allocate one. The former is extremely clumsy, and
the latter shouldn't be done in a RT context. That's assuming that the event's virtual
execute() has access to
all it needs. In all cases I've encountered that is not the case:
the event triggers something in the context where it is received
and processing it requires access to that context's data.
It's a problem for which I don't know a clean C++ solution.
depending on the exact type of thing you're talking about, isn't this
is place for closures, functors, etc. etc. ? What I'm missing in C++ is a built-in
'functor' type that can
simply be assigned from any object::method, with the user being
responsible for the existence of the object and for supplying the
right arguments at the time the functor is called.
both boost::function and sigc::mem_fun serve these roles for me. i've
stopped using sigc::mem_fun for anything other than GUI event
callbacks because sigc++ is fundamentally not thread safe, but the
easy syntax of both these forms is similar.