Qt signals and slot documentation contains misinformation

On: http://doc.qt.nokia.com/4.7/signalsandslots.html

There is a paragraph:

"Older toolkits achieve this kind of communication using callbacks. A callback is a pointer to a function, so if you want a processing function to notify you about some event you pass a pointer to another function (the callback) to the processing function. The processing function then calls the callback when appropriate. Callbacks have two fundamental flaws: Firstly, they are not type-safe. We can never be certain that the processing function will call the callback with the correct arguments. Secondly, the callback is strongly coupled to the processing function since the processing function must know which callback to call."

Which doesn't seem factually correct, and seems like quite an unprofessional attack on Qt signal alternatives.

With no intentions of being rude, but my criticism of the paragraph:

> Older toolkits achieve this kind of communication
> using callbacks.

I don't think this is a fair statement, callbacks are used in very well designed libraries (including very modern ones). A callback is far more than just a function pointer

> A callback is a pointer to a function, so if
> you want a processing function to notify you
> about some event you pass a pointer to another
> function (the callback) to the processing function.
> The processing function then calls the callback when appropriate.

I'm not sure why it's necessary to go into the details of callbacks, especially with such a convoluted definition. A better description might be "A callback is a reference to some code that that should be executed after certain conditions". Or something like that

> Callbacks have two fundamental flaws: Firstly, they are not type-safe.

This seems a bit misguided, even something like a callback with a C function pointer (without arbitrary data) is typesafe. And modern c++ (STL functional, boost bind, sigc etc.) have generalized callbacks in a completely typesafe manner.

> We can never be certain that the processing function
> will call the callback with the correct arguments.

This seems to imply callbacks are more unreliable than Qt signals, but on account of callbacks being type-safe, the opposite is true.

> Secondly, the callback is strongly coupled to the processing
> function since the processing function must know which callback to call.

Again, this makes little sense. A callback is in no way more coupled than signals/slots. That's why it uses a callback rather than directly executes something.