MOC: signals and slots can't be on same line
-
Feel free to provide a patch to moc for your usecase :)
@Christian-Ehrlicher The issue I have is in regards to what specifically MOC is struggling with.
moc -Eshows the correct output. -
If I can get confirmation that this is intended behavior, I will just revert to using 2 macros. I just want to make sure this isn't a bug.
-
As it does not work it's not implemented in moc so it's a not intended use case. If you want this feature provide a patch, maybe it gets integrated.
-
As it does not work it's not implemented in moc so it's a not intended use case. If you want this feature provide a patch, maybe it gets integrated.
@Christian-Ehrlicher doesn't work != not implemented. As I said before I want to make sure it's not a bug. The same code written out without macros works fine, and the macros are all expanded correctly according to
moc -E. -
Please show a header which does not work, without any macros so we can see what you really want and what not work.
-
did you try the inline versions?
#define SIGNAL_SLOT(NAME, ...) \ Q_SLOT void update_ ## NAME(__VA_ARGS__); \ Q_SIGNAL void NAME ## _changed(__VA_ARGS__)@VRonin Yes this works!! Thank you for addressing the problem 😌 I guess I am still a bit of a Qt newbie, since I've never heard of those inline annotations, but they are super useful for macros like these!
-
Please show a header which does not work, without any macros so we can see what you really want and what not work.
@Christian-Ehrlicher I believe I have found the underlying issue:
Expanding the macros to exactly their output:
class Foo : public QObject { Q_OBJECT // ... public slots: void update_property(bool); signals: void property_changed(bool); protected: bool property; };does not compile either (same linker errors with the signals). You can't have
slotsandsignalson the same line. However, C++ is meant to be a whitespace-insensitive language, so I still think this is a bug in MOC, albeit a different one. I will change the title. -
Even it's a 'bug' in moc it will unlikely to be changed, and when then not before 6.3 so ... don't see why this is needed though.
-
@Christian-Ehrlicher I believe I have found the underlying issue:
Expanding the macros to exactly their output:
class Foo : public QObject { Q_OBJECT // ... public slots: void update_property(bool); signals: void property_changed(bool); protected: bool property; };does not compile either (same linker errors with the signals). You can't have
slotsandsignalson the same line. However, C++ is meant to be a whitespace-insensitive language, so I still think this is a bug in MOC, albeit a different one. I will change the title.@mattfbacon said in MOC: signals and slots can't be on same line:
C++ is meant to be a whitespace-insensitive language, so I still think this is a bug in MOC
Yes, C++ is meant to be whitespace-insensitive. However, moc currently parses files using a custom text processor, not a full-fledged C++ engine. The processor currently doesn't support having "signals:" and "slots:" on the same line.
If you're interested, here's an experiment that reimplements moc on top of
libclang, which gives it more capabilities in understanding arbitrary C++: https://woboq.com/blog/moc-with-clang.html -
@mattfbacon said in MOC: signals and slots can't be on same line:
C++ is meant to be a whitespace-insensitive language, so I still think this is a bug in MOC
Yes, C++ is meant to be whitespace-insensitive. However, moc currently parses files using a custom text processor, not a full-fledged C++ engine. The processor currently doesn't support having "signals:" and "slots:" on the same line.
If you're interested, here's an experiment that reimplements moc on top of
libclang, which gives it more capabilities in understanding arbitrary C++: https://woboq.com/blog/moc-with-clang.html@JKSH Interesting. Looks like
moc-ngis fully functional; I will have to try that on my project. -
@JKSH Interesting. Looks like
moc-ngis fully functional; I will have to try that on my project.@JKSH Scratch that, just realized that the project is almost two years old and won't compile. Really,
mocshould be using a full C++ parser... -
Even it's a 'bug' in moc it will unlikely to be changed, and when then not before 6.3 so ... don't see why this is needed though.
@Christian-Ehrlicher It's not strictly needed but without it the
signals:andslots:section labels don't work like others. This makes signals and slots a leaky abstraction. This is especially true when you consider that Qt 5mocis supposed to support macros, but macros can't have newlines so they are forced to put it all on the same line. In this context, unless you want to mark everything inline withQ_SLOTandQ_SIGNAL(and $DEITY forbid your macro actually wants to change the context for code after it), you're out of luck. -
@JKSH Scratch that, just realized that the project is almost two years old and won't compile. Really,
mocshould be using a full C++ parser...@mattfbacon said in MOC: signals and slots can't be on same line:
Really,
mocshould be using a full C++ parser...I agree, that would be ideal.
However, something like libclang did not exist when moc was invented. To reimplement it now with libclang is a costly and risky exercise. Can you show that the benefits outweigh the risks?
-
@JKSH Scratch that, just realized that the project is almost two years old and won't compile. Really,
mocshould be using a full C++ parser...@mattfbacon said in MOC: signals and slots can't be on same line:
Really, moc should be using a full C++ parser...
Again: feel free to provide a patch instead blaming around that a corner case does not work...
