[tcbawo]

> most debuggers just show you two opaque addresses

This has not been my experience. But I haven't needed to deal with RTTI disabled.

By RAII, I mean using destructors to unregister a callback. This covers 99.9% of use cases. Generally callback registration is not where you really want type erasure anyways.

[mwkaufma]

>> By RAII, I mean using destructors to unregister a callback.

_Whose_ destructor, if not the receiving-type? Is there a third "binding" object, because then you have three potentially-unrelated lifetimes.

>> Generally callback registration is not where you really want type erasure anyways.

I'm responding to the article: "Some mechanisms for doing callbacks require a modification to, or derivation of, the caller or callee types. The fact that an object is connected to another object in a particular application often has nothing to do with its type. As we'll see below, mechanisms that are type intrusive can reduce the flexibility and increase the complexity of application code. "

[tcbawo]

> Whose_ destructor, if not the receiving-type

The receiving type should control the lifetime of any callbacks to itself that it gives away. The destructor is the best place to ensure this gets properly cleaned up.

Like anything, custom callbacks can be used well or misused. Design is a matter of expertise and taste bordering on an art form. Connecting framework implementation and business logic can be done cleanly or clumsily. I am skeptical of an argument that callbacks have a code smell prima facie.

[mwkaufma]

I don't disagree, but the article does. RH describes an architecture where setup functions create callbacks, independent of the receiving type. If I were to steelman him, it would be something like this: "in a pedantic MVC system, model objects don't depend on view objects by design, and therefore should not be aware that their methods are used as 'click callbacks'"