3 ms·

Nope, Qt 6 still uses moc. I don't think modern C++ metaprogramming is quite capable of entirely replacing moc. The closest thing I'm aware of is [0], but it re

Nope, Qt 6 still uses moc. I don't think modern C++ metaprogramming is quite capable of entirely replacing moc. The closest thing I'm aware of is [0], but it requires additional macros compared to what moc requires, and compilation speed can suffer. Chances are moc won't be dropped until full reflection lands, if ever, and even then if compilation speed is too bad I wouldn't be entirely surprised if moc remains. [0]: https://github.com/woboq/verdigris https://github.com/woboq/verdigris

justin66 4y ago
Apart from just not having all the widgets, why do you think CopperSpice falls short? Getting rid of the moc was pretty much the first thing they accomplished.
- jchw 4y ago
  It is possible to get rid of moc by manually writing out the equivalent code (using macros or not) or gutting out features that require it. Qt uses it to do things that would otherwise not be possible, like expose QObjects to scripting languages. That requires reflection that modern C++ doesn't support and thus needs either redundancy of some kind (to generate the necessary metadata to do 'reflection') or code generation (to generate the necessary metadata to do 'reflection'). MOC was never simply superfluous.
- jcelerier 4y ago
  > Getting rid of the moc was pretty much the first thing they accomplished. but it's not a proper replacement. With Qt's moc you just annotate the class: class Foo { Q_OBJECT Q_SIGNAL void f(int a, int b); Q_INVOKABLE void g(int c, int d); }; with CopperSpice (and verdigris, and anything else that does not use an external code generator) you have to repeat all the names and use much more macros: class Foo { CS_OBJECT(Foo) CS_SIGNAL_1(Public, void f(int a, int b)); CS_SIGNAL_2(f, a, b); CS_INVOKABLE_METHOD_1(Public, void g(int c, int d)); CS_INVOKABLE_METHOD_2(g, c, d); };
- aw1621107 4y ago
  jcelerier and jchw basically said what I was going to say. All I have to add is that getting rid of moc in and of itself is not the end goal here; it's getting rid of moc without needing to change anything else. Until then, moc is providing something that C++ itself cannot.
- richm44 4y ago
  See https://woboq.com/blog/verdigris-qt-without-moc.html https://woboq.com/blog/verdigris-qt-without-moc.html for detailed breakdown
jcelerier 4y ago
yep, a big part of moc is about generating reflection info and current C++ metaprogramming very simply does not cover reflection and even less custom code generation (think generating a function called "auto foo_info()" from a function "void foo()" automatically - right now the only way to do this if one does not want to use macros is through an external code generator, e.g. in CMake or whatever).

justin66 4y ago

Apart from just not having all the widgets, why do you think CopperSpice falls short? Getting rid of the moc was pretty much the first thing they accomplished.

jchw 4y ago
It is possible to get rid of moc by manually writing out the equivalent code (using macros or not) or gutting out features that require it. Qt uses it to do things that would otherwise not be possible, like expose QObjects to scripting languages. That requires reflection that modern C++ doesn't support and thus needs either redundancy of some kind (to generate the necessary metadata to do 'reflection') or code generation (to generate the necessary metadata to do 'reflection'). MOC was never simply superfluous.
jcelerier 4y ago
> Getting rid of the moc was pretty much the first thing they accomplished. but it's not a proper replacement. With Qt's moc you just annotate the class: class Foo { Q_OBJECT Q_SIGNAL void f(int a, int b); Q_INVOKABLE void g(int c, int d); }; with CopperSpice (and verdigris, and anything else that does not use an external code generator) you have to repeat all the names and use much more macros: class Foo { CS_OBJECT(Foo) CS_SIGNAL_1(Public, void f(int a, int b)); CS_SIGNAL_2(f, a, b); CS_INVOKABLE_METHOD_1(Public, void g(int c, int d)); CS_INVOKABLE_METHOD_2(g, c, d); };
aw1621107 4y ago
jcelerier and jchw basically said what I was going to say. All I have to add is that getting rid of moc in and of itself is not the end goal here; it's getting rid of moc without needing to change anything else. Until then, moc is providing something that C++ itself cannot.
richm44 4y ago
See https://woboq.com/blog/verdigris-qt-without-moc.html https://woboq.com/blog/verdigris-qt-without-moc.html for detailed breakdown

jcelerier 4y ago

yep, a big part of moc is about generating reflection info and current C++ metaprogramming very simply does not cover reflection and even less custom code generation (think generating a function called "auto foo_info()" from a function "void foo()" automatically - right now the only way to do this if one does not want to use macros is through an external code generator, e.g. in CMake or whatever).