Re: [boost] Interest in non-intrusive signal/slot lib?

Subject: Re: [boost] Interest in non-intrusive signal/slot lib?
From: Peter Dimov (lists_at_[hidden])
Date: 2015-05-20 11:44:23

Vicente J. Botet Escriba wrote:
Le 20/05/15 15:25, Sylvester-Bradley, Gareth a écrit :
> On 20 May 2015 14:13, Vicente J. Botet Escriba wrote:
...
>> struct C {
>>       T1 e1;
>>       T2 e2;
>> };
...
> > Doesn't an aliasing shared_ptr work for this?
> >
> > I.e. boost::shared_ptr<T>(c, &c->e1)
>
> Wow, I missed this functionality.
>
> Thanks a lot for sharing,

Yes, this is the motivating example for the aliasing constructor. It's also 
useful when you have some tree-like data structure in which the inner, say, 
XWidgets, are owned by the root one, and you have a shared_ptr to the root, 
but the root does not use shared_ptr to hold the children. So you use the 
aliasing constructor to create a shared_ptr that points to the inner 
XWidget, but shares ownership with the root shared_ptr. You can then make a 
weak_ptr from that, and then use that weak_ptr as an emitter.

Something like, in more or less pseudocode

    shared_ptr<XWidget> p = load_UI_from_file( "description.xml" );
    XWidget * inner = find_by_id( p.get(), "ID_OK" );
    shared_ptr<XWidget> p2( p, inner );
    // connect to p2's button_down (or whatever) signal

Here load_UI_from_file is a third-party function from the XWidget library 
that creates a tree of XWidgets based on the description in the XML.

To tie this with the other question, note that it's not possible to tell 
this function to use MyWidgetWrapper objects instead, into which we could 
have put signal objects. So if we had to use signal objects, we'd have 
needed to figure out where to place them.