4 ms·

My biggest gripe with MOC is that it makes it no longer C++ and if I just want to quickly throw together some sample code and build it with a makefile I can't.

My biggest gripe with MOC is that it makes it no longer C++ and if I just want to quickly throw together some sample code and build it with a makefile I can't. This still requires the use of a separate header file with is annoying but a lot less annoying than writing in a language which is not c++ and which does not work with a simple toolchain.

jcelerier 7y ago
You don't need a separate header, you can just do #include "foo.moc" at the end. I'd be interested in knowing in which way it is no longer c++, considering Q_OBjECT, signals, slots, ... are just plain cpp macros (see qobjectdefs.h).
- inetknght 7y ago
  > I'd be interested in knowing in which way it is no longer c++, considering Q_OBjECT, signals, slots, ... are just plain cpp macros (see qobjectdefs.h). It's been a while since I've used Qt but if I recall correctly MOC also parsed and read the user interface files to generate the headers which get included in the C++ source.
  - simion314 7y ago
    You are not forced to use the designer tool, you can build the GUI with C++ directly if you need that for some reason.
    - slavik81 7y ago
      There's also a stand-alone designer you can use on individual ui files. In general, there's no need to have the whole project in Qt Creator just to edit a ui file. You can also edit the ui files in a normal text editor. They're just XML files that specify the widget hierarchy to construct. If you have a few example files to work from, they're pretty straight-forward to understand and modify. Validating your changes using designer is definitely faster than recompiling your program, but it's an option.
  - blattimwind 7y ago
    No, that's what uic does.
- ailideex 7y ago
  > You don't need a separate header, you can just do #include "foo.moc" at the end. I was talking about verdigris for which you have to do #include "wobjectimpl.h" > I'd be interested in knowing in which way it is no longer c++, considering Q_OBjECT, signals, slots, ... are just plain cpp macros (see qobjectdefs.h). If it was pure C++ then I would not need to run a MOC to generate working executables. While they are also plain CPP macros they have semantics which is only understood by the MOC and is not captured by CPP or C++. This additional semantics is the reason why they are used in the first place because if it was not for the additional semantics again you would not need MOC.
  - johannes1234321 7y ago
    All my types (and `#define`s) have some semantic meaning only I and non of my tools understand. It is nice if a tool understands those and for an `emit` suggests only my signals for auto-completion, but if it lists them along all other members it is fine. So I can see the argument from a puristic view, but in practice, once my built is setup to run it (cmake automoc or something), it simply works. My issue with Qt is that the API design comes from days very long ago, where they did fantastic work on keeping compatibility, while not adopting to "modern C++" which always requires me to rethink the way I write code. Also integrating with non-Qt code isn't always easy due to reliance on QString (which has value Unicode features), QList (which meanwhile has many std-like APIs) etc. which easily travel through all layers. Thus when staying inside At it's really nice and quite consistent, but integrating is hard.
    - ailideex 7y ago
      > All my types (and `#define`s) have some semantic meaning only I and non of my tools understand. If it is not semantics essential to the correct operation of your program then this is a different matter. I really am not sure what the contention here or misunderstanding is. When I write C++ I write it for a C pre-processor and C++ compiler to read in order to obtain a output program which does something specific and in line with the C++ standard. This is not some high minded purism - this is just pragmatic reality. If I write something in my source which I expect to result in specific output but the specific output cannot be obtained if I use a standard compliant C Preprosessor and C++ Compiler then either my expectation is wrong or I'm writing something which is not C++. So if you don't rely on the behaviour that results from MOC being part of the toolchain then sure - you are writing C++ - if you do - it is not C++. If the semantics (in a sense where it actually affects output) is part of a language, which it is, then changing the semantics of the language makes it a different language. > So I can see the argument from a puristic view, but in practice, once my built is setup to run it (cmake automoc or something), it simply works. This does not make it C++.

jcelerier 7y ago

You don't need a separate header, you can just do #include "foo.moc" at the end. I'd be interested in knowing in which way it is no longer c++, considering Q_OBjECT, signals, slots, ... are just plain cpp macros (see qobjectdefs.h).

inetknght 7y ago
> I'd be interested in knowing in which way it is no longer c++, considering Q_OBjECT, signals, slots, ... are just plain cpp macros (see qobjectdefs.h). It's been a while since I've used Qt but if I recall correctly MOC also parsed and read the user interface files to generate the headers which get included in the C++ source.
- simion314 7y ago
  You are not forced to use the designer tool, you can build the GUI with C++ directly if you need that for some reason.
  - slavik81 7y ago
    There's also a stand-alone designer you can use on individual ui files. In general, there's no need to have the whole project in Qt Creator just to edit a ui file. You can also edit the ui files in a normal text editor. They're just XML files that specify the widget hierarchy to construct. If you have a few example files to work from, they're pretty straight-forward to understand and modify. Validating your changes using designer is definitely faster than recompiling your program, but it's an option.
- blattimwind 7y ago
  No, that's what uic does.
ailideex 7y ago
> You don't need a separate header, you can just do #include "foo.moc" at the end. I was talking about verdigris for which you have to do #include "wobjectimpl.h" > I'd be interested in knowing in which way it is no longer c++, considering Q_OBjECT, signals, slots, ... are just plain cpp macros (see qobjectdefs.h). If it was pure C++ then I would not need to run a MOC to generate working executables. While they are also plain CPP macros they have semantics which is only understood by the MOC and is not captured by CPP or C++. This additional semantics is the reason why they are used in the first place because if it was not for the additional semantics again you would not need MOC.
- johannes1234321 7y ago
  All my types (and `#define`s) have some semantic meaning only I and non of my tools understand. It is nice if a tool understands those and for an `emit` suggests only my signals for auto-completion, but if it lists them along all other members it is fine. So I can see the argument from a puristic view, but in practice, once my built is setup to run it (cmake automoc or something), it simply works. My issue with Qt is that the API design comes from days very long ago, where they did fantastic work on keeping compatibility, while not adopting to "modern C++" which always requires me to rethink the way I write code. Also integrating with non-Qt code isn't always easy due to reliance on QString (which has value Unicode features), QList (which meanwhile has many std-like APIs) etc. which easily travel through all layers. Thus when staying inside At it's really nice and quite consistent, but integrating is hard.
  - ailideex 7y ago
    > All my types (and `#define`s) have some semantic meaning only I and non of my tools understand. If it is not semantics essential to the correct operation of your program then this is a different matter. I really am not sure what the contention here or misunderstanding is. When I write C++ I write it for a C pre-processor and C++ compiler to read in order to obtain a output program which does something specific and in line with the C++ standard. This is not some high minded purism - this is just pragmatic reality. If I write something in my source which I expect to result in specific output but the specific output cannot be obtained if I use a standard compliant C Preprosessor and C++ Compiler then either my expectation is wrong or I'm writing something which is not C++. So if you don't rely on the behaviour that results from MOC being part of the toolchain then sure - you are writing C++ - if you do - it is not C++. If the semantics (in a sense where it actually affects output) is part of a language, which it is, then changing the semantics of the language makes it a different language. > So I can see the argument from a puristic view, but in practice, once my built is setup to run it (cmake automoc or something), it simply works. This does not make it C++.