[Interest] A suggestion about replacing signals, actions and slots

[Charley Bay]

>
> > <snip, (proposal), replace signals/slots with function-pointer?>
>
 > I hope, this stuff can be better (with a way below we do not need to use
> moc, qmake and have an overhead in Qt library)


André already said it (and I agree), but I'll assert clearly:

  "moc" is a code generator.

You get stuff with a code generator that is not possible with
function-pointers alone (see below).

André respondeth:

> There is nothing special about 'slots:' or 'signals:' or even 'emit'.
> You don't even need to use them if you don't want to. Use Q_SLOT or
> Q_SIGNAL instead if you prefer, and if you want, you can leave out the
> emit completely.
>

Agree.

André again::

> 3rd, Qt's signals and slots do a lot more than a vanilla function
> pointer will ever do. Or can that transparently handle threading? Queued
> connections, blocking if needed? Type safety? Provide information on who
> triggered the signal? Work with mis-matched argument lists? Work with
> signal-signal connections? Provide many-to-many relationships between
> the caller (signal) and the callee (slot)? Signals & slots do provide
> all that.
>
> Other toolkits have also seen all this value, and actually copied the
> concept. <snip>


Agree again.

Many years ago (8+?) I read a blog post that said something to the effect
of,

  "moc is the greatest thing that ever happened to C++".

It took me years to understand that at a deeper level.  "moc" is a
code-generator.  Yes, that implies your build process needs to incorporate
that step.  However, there is nothing wrong with code generation, and it's
employed as an adaptive technology to ensure forward-compatibility, promote
good design, expand programmer productivity, eliminate user error, and
provide for elegant binding across adaptive technologies.

"moc" does all these things.  Specific real-world examples are found in the
features mentioned above by André, but IMHO, that (very good) list leaves
out a *lot* more that could have been included.

For example, the "dynamic-property/run-time-attribute" discovery/reflection
is now possible in C++ because of "moc".  It enables the C++
statically-typed (compile-time-typed) language to reflect runtime
attributes like you have in Python or Java.  That enables whole new
programming styles in C++ (e.g., QML property-binding).

Regarding, "new programming paradigms", I've read a number of articles
related to "C++ scripting" and "Dynamic C++" (do a web search), and those
aren't possible without runtime-property-reflection, which is not native to
the C++ language.  You need a code generator.  That's why database
interfaces, three-tier/distributed application processing, and many
technology interfaces rely upon code-generators (e.g., everything using an
"IDL" employs a code-generator).  "moc" merely makes that easy with a few
macros in C++, not requiring a different file format (e.g., the code
generation happens transparently in a build step from your *.hpp/*.cpp
files).

Similarly, "moc" was a solution to cross-platform coding issues, and it
still serves a purpose there.  The "moc" code generator can be improved in
many ways based on the "meta-object-internals" (and it was for Qt5) without
anyone needing to change their C++ code.  That is very valuable.

Lastly, in case it gets lost in the detail, I want to highlight one item
in André's list:  The Qt signals/slots as implemented through the
moc-code-generator provide a "thread-safe-bridge" between objects in
different threads, which are not coupled to each other (e.g., they don't
include each other's headers).  That is incredibly valuable, and likely not
possible without giving up type-safety and other features in a
non-code-generator solution, such as through function-pointers and
compile-time-template-code-generation.

I now very strongly agree with that can't-remember-his-name-blogger-guy
from years ago:

"I'm a hard-core C++ guy.  I don't derive everything from QObject.
>  However, "moc" is the *best* thing that ever happened to C++."


--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20121227/c0210e89/attachment.html>