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