Linked by Thom Holwerda on Wed 7th May 2008 08:54 UTC, submitted by elsewhere
Thread beginning with comment 313276
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Almost nobody calls moc manually. It is the job of your build-system to call it for you or to let 'make' call it for you. For example the KDE projects uses CMake and therefore KDE developers never run the MOC manually. Even, say, on the Windows platform, CMake can generate Visual Studio project files and have the MOC be automatically run, I believe (I have no experience with that, though). So, from the point for view of build automation, the MOC is just like the compiler, the linker, etc. Nothing specific to it. By the way Trolltech doesn't 'sponsor' any IDE, as far as I know.
No doubt that the MOC has many benefits, but some programmers (myself included) may not use the IDEs sponsored by Qt, and therefore having to call the MOC manually. If Qt also supported signals and slots templates, there would not be a need to invoke the MOC manually.
You don't need to invoke MOC manually, even if you do not use an IDE with Qt integration.
Basically all IDEs are capable of working with a Makefile based project, at least I don't know anyone which doesn't.
And Makefiles generated by qmake contains all the rules for MOC, UIC and a rule to update the Makefile itself if the .pro file changed, making it very pleasent to work with, independent of platform.
Nice additional advantage is that one can use the very same Makefiles for automated builds during the night, again on all platforms (e.g. using nmake and VS commandline compiler cl.exe on Windows)






Member since:
2006-01-02
The concern about replacing parts of the STL has, in my opinion, been adressed in the 4.0 release when Qt was split into smaller modules. For instance, if you use QString in a library, you only need to link to QtCore. That is a reasonable dependency just like another. It is much lighter than linking to all of Qt -- which practically no app or library does.
And by the way who said C++ was an immuable thing that nobody may improve except for an ISO committee
Some more info here:
It is perfectly OK to replace the standard library and Qt is certainly not the only such alternative. For example Boost also provides replacements for many classes, and I think that GTK (and GTKmm) also does. The standard library is rather old-fashioned and C++ programming has evolved since the times when it was designed, 20 years ago. You mention better unicode support as an advantage of QString over std::wstring, and I would mention at least another one: copy-on-write. Being able to write a function that just returns a QString without paying the overhead of uselessly copying that string, is awesome.
About the Meta-object-compiler, (MOC) what's wrong about it? It provides huge advantages that one just can't achieve otherwise. The biggest one is introspection. Ever wondered why Apple uses Objective C instead of C++? Introspection. The MOC brings introspection to C++, and that's huge. QObjects can e.g. enumerate their own methods, call methods by name, etc. This allows for much more flexible signals-and-slots than is possible with tempate solutions (a la GTKmm). Hugely valuable for a GUI toolkit, to connect to dynamically loaded components. It also improves the i18n system. Trust me the MOC brings enough benefits to justify its existence
http://doc.trolltech.com/4.3/templates.html
Edit: one important precision, the MOC is, like the other Qt tools, Free software released under the GPL 2/3. So it's not at all a "proprietary extension to c++" as is sometimes trolled.
Edited 2008-05-07 14:31 UTC