Re: [boost] Re: Formal Review: Signals

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-02-20 12:27:40

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;
}

        Doug