[Interest] Is moc obsolete?

[Till Oliver Knoll]

Am 08.07.15 um 20:56 schrieb Konstantin Tokarev:
> 
> 
> 08.07.2015, 21:26, "Till Oliver Knoll" <till.oliver.knoll at gmail.com>:
>>>  Am 08.07.2015 um 08:57 schrieb Igor Mironchik <igor.mironchik at gmail.com>:
>>>
>>>  Hi,
>>>
>>>  Does anybody know if Qt plans to remove moc in the future releases, let's say in Qt 6?
>>
>> What's wrong with moc? :)
>> ...
> It does not support many C++ features

Okay, got it. So you're not questioning moc as a separate build tool per
see, but rather its (lack of) capabilities when it comes to certain C++
features.

The subject "Is moc obsolete" seemed to imply one wanted to get rid of
any additional build tool (and only be using C++ compilers/linkers).


I must say that I consider myself not a "hard core C++ coder", I try to
stay on the level that the Qt API offers.

Looking at that list in the given link, and given that I mostly write
applications, as opposed to general libraries (where templates can be
useful, for later re-use), I don't see many "unsupported features" that
I miss.

For instance I never had the need for nested C++ classes (for sure not
in combination with signals/slots). Am not saying that this would not be
useful, I simply never encountered this situation.

Then there are several points complaining about unsupported #macros,
e.g. defining a base class via a #macro - really? :) #macros are evil!

Multiple inheritance: yes, sometimes I ran into this issue (my second
class however was always a "pure abstract class" aka "interface" with no
implementation whatsoever!). So QObject needs to come first - big deal.
Not a problem for me... cosmetic issue.

Virtual inheritance - could be useful, but again: nothing I have
encountered myself, so cannot comment on that.

Function pointers as signal arguments: yes, I could imagine some useful
cases here.

I am not quite sure whether the last point - Enums and Typedefs must be
fully qualified for Signal and Slot parameters - is actually a
restriction or rather a feature.

And in the given example ("For example, double and qreal are treated as
different types even though qreal is a typedef for double.") I am
actually not sure whether I'd consider a double equal to a qreal! Yes,
in the end they happen to be the same data structure, but I tend to say
that their types - in the strict sense - are in fact different.


Cheers, Oliver