2015-07-08 22:21 GMT+02:00 Till Oliver Knoll <till.oliver.kn...@gmail.com>:
>
> Am 08.07.15 um 20:56 schrieb Konstantin Tokarev:
> >
> >
> > 08.07.2015, 21:26, "Till Oliver Knoll" <till.oliver.kn...@gmail.com>:
> >>> Am 08.07.2015 um 08:57 schrieb Igor Mironchik <
> igor.mironc...@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.
>
Perhaps not related to the question discussed here, but what I've actually
missed sometimes is to be able to make a class template that is also a
QObject (including Q_OBJECT macro). I'm not sure moc can handle that, at
least not fully. If moc needs to improve, I think that's one of the things
that would be nice if it could support. I believe there was even a patch
for that floating around at some point (can't find a link at the moment),
but I think it needed more work and was rejected.
Regards,
Elvis
>
>
> Cheers, Oliver
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
