Why is Qt better than GTK?

[schmalzler]

Could you tell me where in the standard I can read that the code has to be written by a human being? I never stumbled across such a clause.
The standard also doesn't mention something like a build system, or even that the compiler/linker have to be the only tools allowed during building.
IMHO there is no "border" between standard and non-standard, as long as the code fed to the compile compiles and every single object file/library passed to the linker result in a usable binary (undefined behaviour often doesn't manifest in build/link errors...)

[Uqbar]

It's all about taste, philisophy and, in general, subjective considerations

The only unbiased objective evaluations come, IMO, from numbers.
Define what "a good framework" is and how to measure it.
Then measure both Qt and GTK+ and finally compare the results. 1 is less than 2. That's it. Anything else is just subjective.

MOC is not "just an implementation for reflection". If that was the case, we would have got a set of macros/classes/templates/whatevers.
Instead we got a "whole lot of C++ language extensions" (that's the way I call it). You write code in MOC, not in C++.
Then Qt is not a "C++ framework". it's a MOC one. Just to be precise.

Finally, whether this is "elegant", "effective" or even "reasonable" or "actually needed", I leave this to philosophers.
Try both yourself and make your own evaluations. If you don't have time to, then just toss a coin.

[schmalzler]

MOC is not "just an implementation for reflection". If that was the case, we would have got a set of macros/classes/templates/whatevers.
Instead we got a "whole lot of C++ language extensions" (that's the way I call it). You write code in MOC, not in C++.
Then Qt is not a "C++ framework". it's a MOC one. Just to be precise.

Of course moc is not the implmentation, it's a code generator. There is (as said a thousand times) a set of macros (signals, emit, Q_PROPERTY, ...) and classes (QObject, QMetaObject, QMetaMethod, ...) to declare and use all that fancy stuff. Has nothing to do with "extensions", stop that FUD!
And (as said a thousand times) you write perfectly valid C++ source code. moc is (in contrast to vala) NOT a language of its own.
And (just to be precise) it is a C++ framework, not a "moc" framework.

[erendorn]

Doesn't make any sense... First you said moc is OK, the input is the issue, now it's the missing implementation.
That's what moc is used for. You always can write all the code moc creates on your own. Good luck But why do an error-prone job on your own when you can rely on a tool? It's as simple as integrate some program calls (moc) into the build system (if you don't rely on qmake/cmake/...)

I quoted the C++ Standard. It defines what is standard and what is not. It doesn't matter what's popular, or what's easy to integrate, or what is less error prone.

In order to be "standard" C++, a program must compile AND link. That's written right in the ISO document.
It is all very cool that Qt code still compiles without the moc. But if it lacks definition, then it's not a valid c++ program. If it doesn't make sense to you, I'll lay down all the steps (there are not so many of them):

C++11 (and all previous versions) are ISO standards
The ISO standard requires definitions to be available in libraries or in code
moc input does not contain these definitions => moc input is not standard c++

[schmalzler]

C++11 (and all previous versions) are ISO standards
The ISO standard requires definitions to be available in libraries or in code
moc input does not contain these definitions => moc input is not standard c++

moc input == headers (at least most of the times - you can run moc on .cpp files as well, if it contains class definitions). Headers won't compile without ANY implementation file (if the definitions aren't contained by the header itself - but running a compiler on header files usually is not what the standard expects )
And as stated above: I never saw any hint in the standard, that expresses that all the code that forms the program need to be written by a human being. If you know about something like that just tell me. I would wonder if there was some restriction like that. The C++ standard usually does not tell the coders (be it compiler engineer or application developer) how they have to code in order to achieve a standard conform product, it only tells how it should behave (API-wise, (side)effects of method calls, ...).

[erendorn]

moc input == headers (at least most of the times - you can run moc on .cpp files as well, if it contains class definitions). Headers won't compile without ANY implementation file (if the definitions aren't contained by the header itself - but running a compiler on header files usually is not what the standard expects )
And as stated above: I never saw any hint in the standard, that expresses that all the code that forms the program need to be written by a human being. If you know about something like that just tell me. I would wonder if there was some restriction like that. The C++ standard usually does not tell the coders (be it compiler engineer or application developer) how they have to code in order to achieve a standard conform product, it only tells how it should behave (API-wise, (side)effects of method calls, ...).

Obviously by moc input I mean "The code base before the moc is run". You spot on with your comment that header files without definitions don't compile. If your tool chain produces a valid program with such header, chances are that your tool chain does a bit more than the standard
Oh wait. That's exactly what the moc + standard tool chain does. Add definitions, produce a valid program, do more than the standard.

The standard does not say anything about what generates the code. It does, however, say things about the code actually being there (in text or compiled form). So, obviously, the code base after the moc is run is standard c++ (it can be compiled into a program). The code base before it is run is not. The code base after you manually added all the required definitions is valid. The code before is not.

Of course, all that is based on the assumption that "Qt code" designate the code base before running the moc, but given the limited Qt documentation on how to write the meta object code by hand, it's probably fair.

[schmalzler]

You spot on with your comment that header files without definitions don't compile.

Eh, you don't have any idea of what you are talking about, don't you? Header files usually don't even get compiled (as in "compiled into an object file"), it simply contains declarations and definitions that specify an API. It can contain definitions (class definitions, inline functions, or static _template_ members - be aware of the ODR...), of course.

On the rest of your post:
So we are back at the simple issue "is code generation allowed". If you question it for moc you have to question any autotools-based project. Without the generated config.h it won't compile. So "before the code base went through preprocessing" it was not standard conform.
As the build system traditionally is part of the sources everything is fine: The app.-dev. makes sure the compiler and the linker get standard conform source/object code. And that's everything that matters. Compiling a program that makes use of a build system with manual gcc invocation or a custom-hacked Makefile simply is not supported and makes absolutely no sense.

[erendorn]

Eh, you don't have any idea of what you are talking about, don't you? Header files usually don't even get compiled (as in "compiled into an object file"), it simply contains declarations and definitions that specify an API. It can contain definitions (class definitions, inline functions, or static _template_ members - be aware of the ODR...), of course.

On the rest of your post:
So we are back at the simple issue "is code generation allowed". If you question it for moc you have to question any autotools-based project. Without the generated config.h it won't compile. So "before the code base went through preprocessing" it was not standard conform.
As the build system traditionally is part of the sources everything is fine: The app.-dev. makes sure the compiler and the linker get standard conform source/object code. And that's everything that matters. Compiling a program that makes use of a build system with manual gcc invocation or a custom-hacked Makefile simply is not supported and makes absolutely no sense.

I know that headers don't get compiled, thank you.

On the rest of your post:
Code generation is not standard. Yes, even autotool. "Traditionally" != "standard". "fine" != "standard". "useful" != "standard". "what matters" != "standard".

But as you don't want do accept what standard means, I'll get yet another comparison:
To compile a standard c++ code base you need:
- the source
- any standard compliant c++ tool chain

To compile a qt project you need
- the source
- any standard compliant c++ tool chain
- a moc

Can you spot the difference?

[FLHerne]

There seems to be a problem distinguishing between the C++ standard(s) and the colloquial meaning of that word.
Can we at least agree that moc isn't 'standard' in the latter sense, even if it may be in the former?

I'm not convinced it's either, but moc isn't used at all outside Qt-based development.

[schmalzler]

Again: the "C++ standard" as in the official ISO/IEC document (erendorn tried to argue with quoting it) does not mention any tools, especially it does not mention any sources where code has to come from, be it human or auto-generated. As long as both or one of you won't come up with a quote of that document that states something else it is your "opinion" that Qt programs are not standard C++.
Even if moc, uic, rcc are tools that Trolltech invented to make Qt development easier they are not explicitly forbidden. This discussion originally was about the "extension" to the language or that Qt was a different programming language - which it is definitely not.
If you now start a discussion about the bare set of allowed tools you even have to forbid make...

And I now will stop answering as everything was said often enough...