Re: Formal Review: Signals

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-20 13:01:05

--- In boost_at_y..., Douglas Gregor <gregod_at_c...> wrote:
> On Wednesday 20 February 2002 10:14 am, you wrote:
> > Now back to the original problem I was trying to solve.  Since I'd
> > like to avoid deriving from trackable there are instances where I 
can
> > see using "controlling" boost::connection member variables to 
manage
> > this instead.  But the two lines of code required to copy the
> > connection and set the controlling state could be tedious when
> > there's a lot of connections.  So as an alternative to the 
previous
> > suggestion (which won't work with out changing the implementation 
of
> > the controlling state), how about an overloaded constructor?
> >
> > boost::connection con(sig.connect(foo), true /* controlling */);
> >
> > We won't always be able to set this up at construction, so we 
would
> > also need an assign().
> >
> > con.assign(sig.connect(foo), true /* controlling */);
> >
> > Bill Kempf
> 
> Here's one alternative: instead of having the 
optional 'controlling' behavior 
> of connection, why not have two classes 'connection' 
and 'scoped_connection'?
> 
> connection is just a reference to the connection itself. It has 
members 
> 'connected' and 'disconnect'.
> 
> scoped_connection is a connection that will disconnect when it goes 
out of 
> scope. It also has 'connected' and 'disconnected', and a 'release' 
to turn 
> off the disconnect-on-destruct behavior. 
> 
> For a more concrete reference:
> 
> class connection {
> public:
>   bool connected() const;
>   void disconnect();
> };
> 
> class scoped_connection : public conection {
> public:
>   ~connection() { if (mDisconnectOnDestruct) this->disconnect(); }
>   connection release() { mDisconnectOnDestruct = false; return 
*this; }
>   scoped_connection& operator=(const connection&);
> 
> private:
>   bool mDisconnectOnDestruct;
> }

Sounds good to me.

Bill Kempf