> 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.
It generates output but the output is wrong in the sense that when I wrote Q_OBJECT I expected the output to be the result of (MOC -> CPP -> CXX) and not just (CPP -> CXX).
So put differently I expected Q_OBJECT (and what it expands to) to have semantic meaning which is not provided by a standard compliant C Preprosessor and C++ Compiler.
And if it was valid output - i.e. the output is the entirety of what I expected from the input - then I would not need to ever use MOC.
Moc just adds some more generated code next to you valid C++ code, generally in a new translation unit.
That generated code is just boiler plate which you could write by hand if you wanted. In a sense this is what verdigris does: it provides macros that makes makes it easier to "write it by hand" (the W_OBJECT_IMPL macro somehow expends to the code generated by moc)
> Moc just adds some more generated code next to you valid C++ code
Code without which the complete output of your toolchain from your source is incomplete and therefore invalid - again if this was not the case you would not need to run MOC at all.
> the output is wrong in the sense that when I wrote Q_OBJECT I expected the output to be the result of (MOC -> CPP -> CXX) and not just (CPP -> CXX).
That is not really how moc works though ? moc does not change anything to your original sources nor their translation units; it is not an additional preprocessing step, but a parallel one.
This .o is exactly the same that one that would be produced in a complete Qt program. Moc just generates additional source files with the implementation of some functions whose declaration is given by the Q_... macros. You could also write them by hand or generate them with fancy cmake scripts... it's just not a fun experience.
> moc just generates additional source files with the implementation of some functions whose declaration is given by the Q_... macros.
But those additional source files are essential to the operation of my program - if they werent - and it was just entirely optional - why would someone ever opt to run it?
> it is not an additional preprocessing step, but a parallel one.
If I write something and I use QT MOC specials like Q_OBJECT and I do no MOC processing occurs I will never obtain the output I consider as correct as a whole - sure if I don't care about the output as a whole and just look at parts of it then I could say those parts there and correct. But I did not write Q_OBJECT because I like the way it looks in my source file, I wrote it so that MOC could generate some specific code without which my program will not function correctly.
> This .o is exactly the same that one that would be produced in a complete Qt program.
Say I had a program (XPP) that for all valid c++ input generates the output that a c++ compiler would generate for:
// blank
Would it be a C++ compiler? And if not why not? I could also tell people that the .o file it generates is the same as would be produced by a c++ compiler except there is some additional parts which they can write by hand in the .o file.
When I write c++ I don't just care that some output is generated - if the output is just missing some parts it is still wrong - even if I could go add those parts by hand.
Similarly if I write Qt, I actually care very much that when I put Q_OBJECT that some things end up in the output - because if I did not I would not use MOC.
and indeed :
no moc in sight and that produces a .o file which is the only relevant criterion to decide whether something is semantically C++ or not.