Nur widerspricht das nicht im Geringstem dem, was ich vorher geschrieben habe.
Natürlich interpretiert MOC die Macros anders als der C++ Präprozessor, aber aus Sicht des C++ Präprozessors sind es normale Macros.
Daher kann man auch, wie man wie gesagt leicht selber überprüfen kann, jedes Quelldatei mit einem normalen C++ Compiler übersetzen. Das gilt dann in Folge auch für die von MOC genrierte Datei.
Das bei Qt Projekten ein Teil der Arbeit durch einen Codegenerator übernommen wird reduziert den Aufwand für die Entwickler, aber wenn man aus welchen Gründen auch immer keinen generierten Code haben möchte, kann man gerne die QMetaObject Subklasse implementieren.
Aus mir nicht näher bekannten Gründen scheinen einige Leute zwischen "guten" und "bösen" Codegeneratoren zu unterscheiden, oder einfach wiederzukäuen was wie wo anders gelesen haben, ohne selber die nötigen Kenntnisse über Macros, Präprozessor und generierten Code zu haben.
Insbesondere ist "moc" nicht der C++ Präprozessor (der wenn ich mich nicht irre, im Standard als identisch zum C Präprozessor deklariert ist), und damit ist Code, der nur von moc -> C++ Compiler übersetzt werden kann, kein Standard C++. Wie Du richtig sagst, kann man alles was "moc" tut, auch von Hand tun. Gilt auch für den C++ Präprozessor, am Rande.
Aber wenn moc zum Einsatz kommt, ist der Quellcode per Definition, eben KEIN C++ mehr. Eine C++ IDE etwa muss erst beigebracht bekommen, was QT da meint, wenn sie nur einen C++ Parser hat.
Dass das bedeutungslos ist, darin bin ich mir aber vollkommen sicher. Der betreffende Code wird doch ohnehin mit XML-Dateien (.ui) Dateien eng verheiratet, wo dann der "uic" (User Interface Compiler) C++ erzeugt. Ja, und XML ist ja erst recht mal kein C++, aber schon deutlich kühler, um ne GUI zu machen, wenn man ne GUI wie den QT-Designer hat, wo dann Slots per Drag&Drop verbunden werden.
Ich finde gut, das Trolltech den Mut hat, viele Sachen noch mal neu und besser zu erfinden. Damit schaffen sie eine Insel, aber dank der hohen Investitionen in QT, ist die schon lange gross genug.
Die Kritik an QT richtet sich daher doch nur daran, dass die, die ihren Sourcecode behalten wollen, für den von Trolltech einen pro-Entwickler Obulus zahlen müssen, um QT zu verwenden.
Sollen die mal lieber Gtkmm nehmen, da haben sie bestes Standard C++, dann wird auch std::string benutzt, kein QString (der dafür dann aber auch viel mehr kann). Ironie: Nun gut, darin entwickeln ist etwas teurer, aber bei den _Unmengen_ gesparter Lizenzgebühren, und angesichts der Tatsache, dass dann Niemand sonst den Source sehen darf, kommt das ja locker wieder rein. ,-)
sry, Kay, aber Kevin hat da recht. Die Stichwörter 'slots', 'signals', 'SLOT', 'SIGNAL' und 'Q_OBJECT', sind gemäß des C++ Standards stinknormale Makros. Wenn man auf Signals+Slots verzichten möchte, kann man den Moc-Lauf auch sein lassen. Durch Definition von Q_MOC_RUN wird für diesen die Bedeutung der Qt-Stichwörter verändert. All das findet sich in der qobjectdefs.h.
Nur widerspricht das nicht im Geringstem dem, was ich vorher geschrieben habe.
Natürlich interpretiert MOC die Macros anders als der C++ Präprozessor, aber aus Sicht des C++ Präprozessors sind es normale Macros.
Daher kann man auch, wie man wie gesagt leicht selber überprüfen kann, jedes Quelldatei mit einem normalen C++ Compiler übersetzen.
Das gilt dann in Folge auch für die von MOC genrierte Datei.
Das bei Qt Projekten ein Teil der Arbeit durch einen Codegenerator übernommen wird reduziert den Aufwand für die Entwickler, aber wenn man aus welchen Gründen auch immer keinen generierten Code haben möchte, kann man gerne die QMetaObject Subklasse implementieren.
Aus mir nicht näher bekannten Gründen scheinen einige Leute zwischen "guten" und "bösen" Codegeneratoren zu unterscheiden, oder einfach wiederzukäuen was wie wo anders gelesen haben, ohne selber die nötigen Kenntnisse über Macros, Präprozessor und generierten Code zu haben.
Insbesondere ist "moc" nicht der C++ Präprozessor (der wenn ich mich nicht irre, im Standard als identisch zum C Präprozessor deklariert ist), und damit ist Code, der nur von moc -> C++ Compiler übersetzt werden kann, kein Standard C++. Wie Du richtig sagst, kann man alles was "moc" tut, auch von Hand tun. Gilt auch für den C++ Präprozessor, am Rande.
Aber wenn moc zum Einsatz kommt, ist der Quellcode per Definition, eben KEIN C++ mehr. Eine C++ IDE etwa muss erst beigebracht bekommen, was QT da meint, wenn sie nur einen C++ Parser hat.
Dass das bedeutungslos ist, darin bin ich mir aber vollkommen sicher. Der betreffende Code wird doch ohnehin mit XML-Dateien (.ui) Dateien eng verheiratet, wo dann der "uic" (User Interface Compiler) C++ erzeugt. Ja, und XML ist ja erst recht mal kein C++, aber schon deutlich kühler, um ne GUI zu machen, wenn man ne GUI wie den QT-Designer hat, wo dann Slots per Drag&Drop verbunden werden.
Ich finde gut, das Trolltech den Mut hat, viele Sachen noch mal neu und besser zu erfinden. Damit schaffen sie eine Insel, aber dank der hohen Investitionen in QT, ist die schon lange gross genug.
Die Kritik an QT richtet sich daher doch nur daran, dass die, die ihren Sourcecode behalten wollen, für den von Trolltech einen pro-Entwickler Obulus zahlen müssen, um QT zu verwenden.
Sollen die mal lieber Gtkmm nehmen, da haben sie bestes Standard C++, dann wird auch std::string benutzt, kein QString (der dafür dann aber auch viel mehr kann). Ironie: Nun gut, darin entwickeln ist etwas teurer, aber bei den _Unmengen_ gesparter Lizenzgebühren, und angesichts der Tatsache, dass dann Niemand sonst den Source sehen darf, kommt das ja locker wieder rein. ,-)
Gruß, Kay
All das findet sich in der qobjectdefs.h.