Why is Qt better than GTK?

[mhogomchungu]

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

You would probably also need a "build system" as things will probably need to be done in a specific order and
different build paths may need to be taken depending on the state of the building system.

The build system will also most likely generate additional header files to aid in conditional compilation.

I doubt it will be trivial to build a large C++ code base if it is not accompanied with its build system tailored to the source code.

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

Look at any sufficiently large C/C++ code base and you will see a dependency on headers and other informations that are not
shipped with the sources but are generated by the build system at compile time.

moc generates additional information at compile time to aid the build process.moc is part of the build system.

If your Qt code is small enough,you can write the code moc was going to generate and skip calling moc.

If the C++ code base is small enough,you can also manually compile each source file yourself,you can also create all
needed header files and other supporting files the sources needs that the build system was going to produce for the code yourself.

Criticizing Qt because of generated C++ code through moc seems to me like barking at the wrong tree.

[erendorn]

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...

Emphasis on extension...

Your position is the following one:
- you can manually rewrite any program from any programing language to c++
- thus any programming language is actually ISO C++. (yay, PHP is ISO C++!)
The C++ standard does not forbid you to write your program in PHP and then translate automatically it to c++. But that operation IS NOT PART OF THE STANDARD.

The c++ standard describes what you can input in a standard c++ toolchain, not how. Qt code describe the code before the additional code is written. If you decide to manually write and maintain it, it's not really Qt anymore. The moc transform Qt specific code into c++ standard code. The moc is not forbidden by the standard. That does not make the moc any standard. And so Qt code not standard: you have to process it first.

You would probably also need a "build system" as things will probably need to be done in a specific order and
different build paths may need to be taken depending on the state of the building system.

Look at any sufficiently large C/C++ code base and you will see a dependency on headers and other informations that are not
shipped with the sources but are generated by the build system at compile time.

Yup. Exactly. Project files, compilator configuration and all that are not standard. That's why every single tool chain has his own. I'm absolutely not saying these are not useful or necessary. But if you want to pass from one tool chain to another, you'll need to rewrite all these parts, because they are not covered by the standard.

Any huge codebase is indeed not standard. The question usually is, "how much work is it to change tools", which is a measure of how much non standard you are. Qt is sufficiently far off, that the question is "how much work is it to port the moc", not really "can I do differently". But at the same time, Qt is sufficiently close enough that code can still be parsed by standard tools.

Criticizing Qt because of generated C++ code through moc seems to me like barking at the wrong tree.

I'm not criticizing Qt.

[mhogomchungu]

Emphasis on extension...
The moc transform Qt specific code into c++ standard code. The moc is not forbidden by the standard. That does not make the moc any standard. And so Qt code not standard: you have to process it first.

That is just not true.

If you have a malformed C++ source file,the C++ compiler will refuse to compile it,it is just that simple.

The fact that any C++ compiler can parse a Qt based C++ source file and generate object code for the source file should be proof enough that the Qt based source file is "C++ standard compliant".If it wasnt standard,the C++ parser would complain about it,its just that simple.

Qt's extensions are just macros that hides the ugly details of how it stretches C++,but those macros live within the rules of the language.

What moc does is generating addition "standard C++" code that glue together the expanded macros.Remove moc and all Qt based code will compile just fine,things will just fail to link because the expected glue will be missing.If you write Qt code,you can write the expected glue yourself,skip moc and things will build and link just fine.Why couldnt they come up with another macro that provided the glue?Who knows,maybe they reached the limit of their collective imaginations.

[ultimA]

Beside phone and tablets, there are a lot more commercial embedded projects that need a GUI, and on many of these, using C++ is a serious no-go. GTK has a pure C interface and is thus not just the clear winner on these platforms, but the only (between gtk and qt) feasable solution. I know this doesn't concern desktop and phone devs, so this is not mean to be an argument for them, but I thought it'd interesting to mention this.

And for all those discussing the meaning of "standard" off-topic, get your own thread.

[Armin]

Well, I'm certainly not a GUI developer, but I liked the talk given by Dirk Hohndel at the Linux.Conf.Au:

http://www.phoronix.com/scan.php?page=news_item&px=MTU2ODM

He illustrated much of the differences between the toolkits from a practical point of few quite nicely, but he is not exactly addressing your question.

I want to know which one is ARCHITECTURALLY better.

....

Please no trolling and flame wars, I want technical answers. And "theme A looks better" doesn't count as technical.

[Luke_Wolf]

Beside phone and tablets, there are a lot more commercial embedded projects that need a GUI, and on many of these, using C++ is a serious no-go. GTK has a pure C interface and is thus not just the clear winner on these platforms, but the only (between gtk and qt) feasable solution. I know this doesn't concern desktop and phone devs, so this is not mean to be an argument for them, but I thought it'd interesting to mention this.

And for all those discussing the meaning of "standard" off-topic, get your own thread.

That may have been true years ago, but I sincerely doubt that there's a modern embedded project that doesn't have access to C++, even the arduino is actually using C++ as opposed to C, and there's kinda this whole Qt Embedded thing http://qt.digia.com/Product/Qt-for-E...d-Development/

[Hοnton]

I'm sorry to tell you all but Qt is C++11 standard compliant period.

Do you all know what is not? Shared libraries!

[erendorn]

That is just not true.

If you have a malformed C++ source file,the C++ compiler will refuse to compile it,it is just that simple.

The fact that any C++ compiler can parse a Qt based C++ source file and generate object code for the source file should be proof enough that the Qt based source file is "C++ standard compliant".If it wasnt standard,the C++ parser would complain about it,its just that simple.

Qt's extensions are just macros that hides the ugly details of how it stretches C++,but those macros live within the rules of the language.

What moc does is generating addition "standard C++" code that glue together the expanded macros.Remove moc and all Qt based code will compile just fine,things will just fail to link because the expected glue will be missing.If you write Qt code,you can write the expected glue yourself,skip moc and things will build and link just fine.Why couldnt they come up with another macro that provided the glue?Who knows,maybe they reached the limit of their collective imaginations.

The standard covers compilation and linking. I quoted the relevant part some pages ago. Qt code does compile, but does not link. Qt code, using standard compliant tools, cannot be made into a valid program (as per the ISO spec).
Qt code is the code without the moc generated code.
The fact that "you can write the code yourself" only underlines further that said code is not written in a Qt project. So, again, Qt code can be made into standard c++ code (that's what the moc does), yet is not standard (try to compile Qt without moc, let me know how it goes).

[schmalzler]

The C++ standard describes how to implement the standard (which also describes the language, of course). According to the C++ stadard, a program exists of one or more translation units (which MAY be translated separately ) linked together.
It never says anything about a tool chain. It does not mention "compiler" or "linker" (if you search the text, you find those terms in notes - informal parts of the standard aimed at implementers, and therefor it uses the usual terms). So having seperate tools to transform your codebase (which IS c++ in Qt's case, not PHP...) into a linkable state is NOT covered by the standard and therefor not explicitly forbidden.

That you have "compilers" and "linkers" was just a natural process (different tool for different task). It could of course be implemented in ONE tool. The standard does NOT say who has to ship those tools. Qt could have written a tool called "qt-cpp-compiler" which internally calls g++ and ld - and creates the qt-internal implementations behind the scenes. It STILL would be standard compliant! Even "qt-cpp-compiler" would be a standard compliant implementation of the c++ language.

In short: You do not need to limit yourself on the "tool chain" offered by your operating system in order to produce a program that copes with the "C++ standard".

[erendorn]

So having seperate tools to transform your codebase (which IS c++ in Qt's case, not PHP...) into a linkable state is NOT covered by the standard and therefor not explicitly forbidden.

Not covered by the standard = not standard. The standard describes what a tool chain must support. If your codebase requires the tool chain to support more than that, it is obviously not standard. That's how standards work.