Why is Qt better than GTK?

[curaga]

I stopped reading here. Plese explain how useful are POSIX skills when developing an Android, iOS, or Windows 8 app ?

Like it or not, this is where is the cash, and where are the most developers.

Way to necro. Anyway, Android does support POSIX partially in its NDK, iOS supports most of it, and on Windows you can use mingw to get most of it.

POSIX skills are way more useful than say WinAPI skills, more portable, and this is not to mention how horrible WinAPI is. If you write POSIX-compatible sw, close to every platform has at least some support for it.

Unless you meant WinPhone, which is completely irrelevant as a platform, though all two users might object.

[erendorn]

Way to necro.

I plead guilty, the spammer bumped the post, and I replied without checking.

Anyway, Android does support POSIX partially in its NDK, iOS supports most of it, and on Windows you can use mingw to get most of it.

POSIX skills are way more useful than say WinAPI skills, more portable, and this is not to mention how horrible WinAPI is. If you write POSIX-compatible sw, close to every platform has at least some support for it.

Unless you meant WinPhone, which is completely irrelevant as a platform, though all two users might object.

But if you use Qt, you'll not have support for most of it, or have something more portable. You'll have the full support right there. And I'd argue it doesn't really count as bloat if it's done at compile time.

[AnonymousCoward]

you can do signal-slots with pure C++ now. but remember that Qt started when there was none or poor implementation of templates which are essential for it. so they had write MOC to overcome this limitation. same reason is why they reimplemented STL library with QVector QList etc. implementations of STL were buggy, poorly written or non existent on some platforms. also some people doesn't want use STL.

[LightBit]

not to mention how horrible WinAPI is.

HANDLE WINAPI CreateFile(
_In_ LPCTSTR lpFileName,
_In_ DWORD dwDesiredAccess,
_In_ DWORD dwShareMode,
_In_opt_ LPSECURITY_ATTRIBUTES lpSecurityAttributes,
_In_ DWORD dwCreationDisposition,
_In_ DWORD dwFlagsAndAttributes,
_In_opt_ HANDLE hTemplateFile
);

Looks like assembler.

[sandy.martel]

what is non-standard C++?

* Qt doesn't use standard C++, instead it uses a layer on top of C++. It just doesn't sound right.

Actually, I'd like to hear "a proper technical explanation" on what is non-standard C++ ? And "I don't like it" doesn't count as technical. :-)

First, every single line of code I write in Qt is fed straight to the compilers, on many different platforms, so it has to be pretty standard C++. Yes, Qt heavily uses #defines and macros and some people don't like to over use #defines (including me!). But the preprocessor is part of the standard C++ deal, it is standard.

The second point usually involves the moc tool used as part of the build process. What the moc tool does is automatic code generation, it takes some input (.h files in this case) and generate standard C++ source code that is, again, fed straight to the compilers. Qt has actually 3 of those tools (moc, uic and qrc). This technique of automatic code generation as part of the build process is at least 30 or 40 years old and is usually used to automate cumbersome or error-prone repetitive coding. bison/yacc, flex/lex comes to mind, or, more recently, Google protocol buffer (that generate serialisation code from idl definition), gsoap (generate xml-soap code from wsdl) and countless others use the same trick. One could argue that automatic C/C++ generation is also used by most open source project in the form of autoconf/automake generating some config.h header file.

So why is Qt "non-standard" ? Because it uses to many macros ? Every projects uses macros, so what is the threshold? What is "too many" ?
Or is it because it rely too much on automatic code generation ? Again, what is "too much" ? Is it OK to automatically generate 1, 2, 3 files ? What is the limit ?

Anyway, this has always sounds to me like a weak argument from Qt haters...

[erendorn]

Actually, I'd like to hear "a proper technical explanation" on what is non-standard C++ ? And "I don't like it" doesn't count as technical. :-)

First, every single line of code I write in Qt is fed straight to the compilers, on many different platforms, so it has to be pretty standard C++. Yes, Qt heavily uses #defines and macros and some people don't like to over use #defines (including me!). But the preprocessor is part of the standard C++ deal, it is standard.

The second point usually involves the moc tool used as part of the build process. What the moc tool does is automatic code generation, it takes some input (.h files in this case) and generate standard C++ source code that is, again, fed straight to the compilers. Qt has actually 3 of those tools (moc, uic and qrc). This technique of automatic code generation as part of the build process is at least 30 or 40 years old and is usually used to automate cumbersome or error-prone repetitive coding. bison/yacc, flex/lex comes to mind, or, more recently, Google protocol buffer (that generate serialisation code from idl definition), gsoap (generate xml-soap code from wsdl) and countless others use the same trick. One could argue that automatic C/C++ generation is also used by most open source project in the form of autoconf/automake generating some config.h header file.

So why is Qt "non-standard" ? Because it uses to many macros ? Every projects uses macros, so what is the threshold? What is "too many" ?
Or is it because it rely too much on automatic code generation ? Again, what is "too much" ? Is it OK to automatically generate 1, 2, 3 files ? What is the limit ?

Anyway, this has always sounds to me like a weak argument from Qt haters...

As a Qt fan: I'd say the moc is the culprit. It's just much more difficult to build Qt code without using Qt tools, hence, not standard.

[sarmad]

Actually, I'd like to hear "a proper technical explanation" on what is non-standard C++ ? And "I don't like it" doesn't count as technical. :-)

First, every single line of code I write in Qt is fed straight to the compilers, on many different platforms, so it has to be pretty standard C++. Yes, Qt heavily uses #defines and macros and some people don't like to over use #defines (including me!). But the preprocessor is part of the standard C++ deal, it is standard.

The second point usually involves the moc tool used as part of the build process. What the moc tool does is automatic code generation, it takes some input (.h files in this case) and generate standard C++ source code that is, again, fed straight to the compilers. Qt has actually 3 of those tools (moc, uic and qrc). This technique of automatic code generation as part of the build process is at least 30 or 40 years old and is usually used to automate cumbersome or error-prone repetitive coding. bison/yacc, flex/lex comes to mind, or, more recently, Google protocol buffer (that generate serialisation code from idl definition), gsoap (generate xml-soap code from wsdl) and countless others use the same trick. One could argue that automatic C/C++ generation is also used by most open source project in the form of autoconf/automake generating some config.h header file.

So why is Qt "non-standard" ? Because it uses to many macros ? Every projects uses macros, so what is the threshold? What is "too many" ?
Or is it because it rely too much on automatic code generation ? Again, what is "too much" ? Is it OK to automatically generate 1, 2, 3 files ? What is the limit ?

Anyway, this has always sounds to me like a weak argument from Qt haters...

I didn't say "I don't like it". I said "it doesn't sound right"

But, speaking seriously, I think erendorn nailed it. It's moc that isn't standard.

[sandy.martel]

I didn't say "I don't like it". I said "it doesn't sound right"

But, speaking seriously, I think erendorn nailed it. It's moc that isn't standard.

So any project using yacc, lex, google protocol buffer, gsoap, or any code generation tool is by definition "non-standard" ?

A "standard" project is allow only to use a compiler and linker and it becomes non-standard if it uses the same compiler/linker to generate intermediate development tools (like the moc) to simplify or add feature to the final product?

Or are some tools allowed, but not the moc? In that case who gets to decide which tools are "standard" and which aren't ?

Sorry all rhetorical, but me think it's still more of an emotional argument than a logical one...

Nothing wrong with having likes and dislikes thought. Don't think I would say I like it, I just see where and why it stand in the tool chain and using helper tools in a language does not create a "non-standard".

[schmalzler]

IMHO the "isn't standard thanks to moc" argument against Qt was the most important one by some Gnome-Devs. At the same time they developed vala as the "next gen of gnome development". Vala only creates C code. Even worse it seems to create bad C code. The vala applications I used some time ago compiled with a bunch of warnings for every single file. As I wanted to help with development this was really a pain...
On the other side I never saw a single warning with Qt's tools...

[erendorn]

So any project using yacc, lex, google protocol buffer, gsoap, or any code generation tool is by definition "non-standard" ?

A "standard" project is allow only to use a compiler and linker and it becomes non-standard if it uses the same compiler/linker to generate intermediate development tools (like the moc) to simplify or add feature to the final product?

Or are some tools allowed, but not the moc? In that case who gets to decide which tools are "standard" and which aren't ?

Sorry all rhetorical, but me think it's still more of an emotional argument than a logical one...

Nothing wrong with having likes and dislikes thought. Don't think I would say I like it, I just see where and why it stand in the tool chain and using helper tools in a language does not create a "non-standard".

What is standard in C++11 is very precisely described in ISO/IEC 14882:2011 / 2011. ISO as "International Organization for Standardization".
The input is fully restricted by the standard, and the compiler and linker are partly so (eg: binary code and even interface is implementation dependent for c++, but the behaviour of the compiled program is not).
For Qt, the moc output is C++ standard, you can pass it to any compiler, but the moc input (with the Qt specific additions) is not, quite simply.

This is not at all emotional. So yes, a project that use code generation for obtaining c++ is not standard c++, end of story. This might or might not be an issue, depending on how portable or easily reimplementable the code generator is. I find it acceptable in Qt case, other may have different opinions.