
Moc myths debunked - Tomte
https://woboq.com/blog/moc-myths.html
======
jbandela1
Raymond Chen in his excellent The Old New Thing blog frequently asks - "What
if two programs did this". What if every large C++ library came with their own
custom preprocessor?

The major issue with moc is that it is evidence that Qt does not think of
itself as just another C++ library that you can plug in to your code, but that
it tries to be _the_ programming environment and the fact that it uses C++ is
just an implementation detail. Moc is only the most visible of the symptom of
the underlying philosophy. It is also evidenced in the QCollections and by
such things as QThread which duplicate much of the C++11 functionality.

When I evaluate a library for my project, I want it to think of itself as
"just another C++ library", not "The Framework that you base everything in
your application around".

Qt is a great illustration of Joe Armstrong's quote "You wanted a banana but
what you got was a gorilla holding the banana and the entire jungle."

~~~
pzone
If I want to write a cross-platform GUI application supporting a single
introspection, threading model and signals/slots mechanism for all members,
then I'm asking for a jungle, not a banana. What parts of Qt would one want to
split out and use separately? C++ stdlib collections not thread safe by
default and cannot be used as drop-in replacements for Qt's collections. Qt's
collections are designed specifically to work nicely inside its general
framework, but would come at a speed cost used naively in some other sort of
project. Also keep in mind that Qt is much older than C++11 and is just now
switching to the standard library for its backend where possible. You can
still use a non-c++11 compliant compiler with Qt 5.6 and utilize QThreads.

It reminds me of the argument that systemd is problematic because it's too big
and complex. Well, sometimes it makes sense to write a complex system for the
sake of ensuring that many complex components interoperate with ease, and
system-wide changes can be coordinated between the libraries.

~~~
vetinari
> What parts of Qt would one want to split out and use separately?

That's the wrong question. The right question is: what are you going to do,
when you need to use 2-3-4-5 libraries and each one of them insist on using
it's own primitives, collections, object hierarchies, etc. Are you going to
spend your youth just writing shims to marshall data among them?

~~~
to3m
I don't know how much C++ you've done, but your "Ahah! BUT WHAT ABOUT"
scenario sounds _exactly_ like virtually every C++ project I've worked on. You
have N libraries, and each library has its own string class and templated
array class, all with different member function names.

The answer to your question is: yes. Usually you're going to do some
transformation or processing when moving from one type to the other, so you
just fold the conversion into that. It's stupid and you roll your eyes and you
just kind of carry on.

~~~
vetinari
> scenario sounds exactly like virtually every C++ project I've worked on

That's exactly the point :). It is not only C++, but also C problem. Maybe
I've grown coddled with Java, Python and a few other languages, where the
third party libraries do agree on the types they use.

------
simfoo
I never understood the problem with moc. It's an extra step during the build
process, yes. But it's quick and very easy to integrate in modern build tools
(for example CMake).

~~~
beagle3
It's been 14 years since I last used a precompiler like moc (it wasn't moc),
and it was a pain - all the nice IDE features (syntax highlighting, code
completion, automatic indentation, source level debugging, etc.) were all
broken in subtle or major ways.

moc (specifically) has a long track record that I would expect this to be
solved -- no experience myself -- but regardless of how easy it is to add
another build step, most precompilation stages are correlated with reduced
tool functionality.

~~~
simfoo
moc isn't a precompiler - it will not change your code in any way! It merely
generates additional code based on your classes containing meta information

------
gear54rus
There was some movement to rewrite QT things in templates or whatever (so that
it's stock C++) but I lost track of it and kinda abandoned C++ altogether.

Have there been progress with this?

~~~
ldite
CopperSpice - it's discussed in the article

~~~
ogoffart
There is also [https://woboq.com/blog/verdigris-qt-without-
moc.html](https://woboq.com/blog/verdigris-qt-without-moc.html)

------
rikkus
This doesn't need to be debated ad infinitum. Is there a single page that can
be pointed to as the authority on what moc is, what it provides, why it works
the way it does, why it's good and why it's bad - and we leave it at that?
It's been around long enough.

------
zerr
What advantages does moc provide compared to C++14/17 facilities?

~~~
i336_
While I'm not 100% on Qt's history, some quick Googling finds references that
suggest moc was around in the Qt2 days, which was 1999, which was before even
C++03 was a thing. So it's mostly a historical relic, now hidden away as much
as possible by things like automoc in cmake.

Also, FWIW, moc-ng is based on libclang, which looks to be vaguely in the
general direction of what you're getting at: [https://woboq.com/blog/moc-with-
clang.html](https://woboq.com/blog/moc-with-clang.html)

------
adrianN
I think this article would be better if it mentioned some more criticisms that
are actually valid. This way it reads very one-sided, especially for people
like me who are not familiar with QT.

~~~
majewsky
> criticisms that are actually valid

Such as? I have developed Qt applications for many years and never noticed
downsides of the moc approach.

