On Tuesday, May 03, 2011, Greg Hickman wrote:

For a connection 'c', if c.connected() == true prior to calling

c.disconnect();

after which c.connected() == false, how can connection::disconnect() be considered a "const" member function since it clearly changes the observable state of a connection?

Signals2 continues to do the same, although if I ever thought much about rationalizing it before, I don't remember doing so now. Anyways, maybe it's because connection objects are just handles to the real connection. So it's like a pointer in that a const pointer just means the pointer can't be reassigned to point at another object, but you can still modify the pointed-at object through it. To make things more concrete, suppose disconnect was non-const. It still wouldn't stop you from making a new non-const connection object that is a copy of the const connection object, and then disconnecting through the non-const connection object. So I guess I'm arguing that the connected() method isn't returning information about the state of the connection object itself, but rather the state of the thing it is a handle to.