MOC: signals and slots can't be on same line

[VRonin]

did you try the inline versions?

#define SIGNAL_SLOT(NAME, ...) \
  Q_SLOT void update_ ## NAME(__VA_ARGS__); \
  Q_SIGNAL void NAME ## _changed(__VA_ARGS__)

[mattfbacon]

@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.

[Christian Ehrlicher]

Please show a header which does not work, without any macros so we can see what you really want and what not work.

[mattfbacon]

@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!

[mattfbacon]

@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 slots and signals on 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.

[Christian Ehrlicher]

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.

[JKSH]

@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]

@JKSH Interesting. Looks like moc-ng is fully functional; I will have to try that on my project.

[mattfbacon]

@JKSH Scratch that, just realized that the project is almost two years old and won't compile. Really, moc should be using a full C++ parser...

[mattfbacon]

@Christian-Ehrlicher It's not strictly needed but without it the signals: and slots: section labels don't work like others. This makes signals and slots a leaky abstraction. This is especially true when you consider that Qt 5 moc is 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 with Q_SLOT and Q_SIGNAL (and $DEITY forbid your macro actually wants to change the context for code after it), you're out of luck.

[JKSH]

@mattfbacon said in MOC: signals and slots can't be on same line:

Really, moc should 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?

[Christian Ehrlicher]

@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...