Boost logo

Boost Users :

Subject: Re: [Boost-users] pattern support for traversing inheritance chain
From: Brian Budge (brian.budge_at_[hidden])
Date: 2012-11-07 18:32:38


On Wed, Nov 7, 2012 at 3:21 PM, Nathan Crookston <nathan.crookston_at_[hidden]
> wrote:

> Hi Brian,
>
>
> On Wed, Nov 7, 2012 at 4:04 PM, Brian Budge <brian.budge_at_[hidden]> wrote:
>
>> Hi all -
>>
>> I have a case where I have a largeish inheritance hierarchy. I will be
>> calling an initialization function on all objects before using them in some
>> fashion.
>>
>> Basically what I need to happen is when I call init() on a Foo the
>> following would occur:
>>
>> void Foo::init() {
>> super::init();
>> // now with the knowledge that anything I inherited is set up, I can
>> set myself up...
>> }
>>
>> When I'm dealing with a situation like you describe (not using
> constructors), I find that Boost.Signals (or Signals2) do what I'm looking
> for.
>
> I generally do something like the following:
>
> class B
> {
> typedef boost::signal<void()> OnInitListener;
> OnInitListener onInit_;
> public:
> boost::signals::connection
> connectOnInitListener(OnInitListener::slot_function_type cb)
> { return onInit_.connect(cb); }
>
> void onInit() { onInit_(); }
> };
>
> class D : public B
> {
> D() { connectOnInitListener(bind(&D::onInitImpl, this)); } // Register
> our onInit handler.
> };
>
> //Repeat for further derivatives.
>
> This means I don't need to state whom I inherit from, the order of calling
> is determined by the order of construction, and if one method doesn't need
> to listen for the onInit signal, everything works as expected.
>
> HTH,
> Nate
>
>
Hi Nate -

Yes, this seems quite useful. With signal connect, I guess it's
more-or-less pushing-back on a list of function objects? When the signal
is called, it iterates the list and calls each function object?

Thanks for the suggestion. Seems like a good way to go.

  Brian



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