Submitted by
“This article focuses primarily on some technical aspects of Qt, Trolltech’s cross-platform C++ toolkit which, as you may know, is the architectural core behind the KDE desktop on Linux. At the end, I show how easy it is to create a simple application without writing a line of code.” More here.
Cross Platform Development with Qt
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Qt is not quite a C++ toolkit – it does not use standard C++, but MOC++ language.
Similar article about C++ toolkit that is in fact even much easier to use, is BSD licensed (->free for commercial applications as well) and even comes with development environment can be found here:
http://www.codeproject.com/useritems/IntroUpp.asp
“Qt is not quite a C++ toolkit – it does not use standard C++, but MOC++ language. ”
Of course it does. Macro programming is part of the language.
UPDATE: you need a separate processor, but it generates valid C++.
Edited 2006-11-20 16:55
UPDATE: you need a separate processor, but it generates valid C++.
Ever heard about original C++ compiler? It processed C++ into C. That classifies Qt as C Toolkit… Oh, wait a moment, C compiler processes C into machine code, so in fact, Qt is machine code toolkit?
Anyway, more seriously, you do not have to spend more than 2 minutes with the article to find out that MOC adds significant features to C++ and that MOC++ is not C++.
“Ever heard about original C++ compiler? It processed C++ into C. That classifies Qt as C Toolkit… Oh, wait a moment, C compiler processes C into machine code, so in fact, Qt is machine code toolkit?
”
So the point is? Who care about original C++ compiler or how Qt classifies? Stop bashing a toolkit in favor of your own toolkit.
“Anyway, more seriously, you do not have to spend more than 2 minutes with the article to find out that MOC adds significant features to C++ and that MOC++ is not C++.”
MOC is just a tool, no big deal. Only you care about subtle things like it’s not part of the language. Haven’t you ever written your own code generator to make your programming easier?
“Ever heard about original C++ compiler? It processed C++ into C. That classifies Qt as C Toolkit… Oh, wait a moment, C compiler processes C into machine code, so in fact, Qt is machine code toolkit?
”
So the point is?
Well, that was a bad attempt at making a little joke…
Anyway, why is it so important what language is Qt written in? For me, it is simply a C++ with trolltech’s extensions, for which I created a term “MOC++” – maybe incorrect, but everybody understands what does it mean.
“Anyway, why is it so important what language is Qt written in? For me, it is simply a C++ with trolltech’s extensions, for which I created a term “MOC++” – maybe incorrect, but everybody understands what does it mean.”
Qt is a C++ toolkit. It’s written in C++ (and uses a tool to generate C++ code so developers have an easier coding life, proven). It’s mainly used by C++ developers. It’s known as a C++ toolkit, not java, not C#, not plain C, but C++. Does a tool like MOC make it less C++ than just hand coded C++? No, it doesn’t. At least not less C++ than what the C++ pre-processor generates when it expands macros.
Edited 2006-11-20 18:14
Qt is a C++ toolkit. It’s written in C++ (and uses a tool to generate C++ code so developers have an easier coding life, proven).
OK, I know that we will not agree about this, but my credit is gone anyway, so let me get it worse a bit more:
I think that C++ code should be able to be processed by C++ compiler out of box – which is not true for Qt sources. I could agree with you about code generation if those generated files would be distributed along with Qt applications sources or if the real C++ was not in fact just intermediate product.
Anyway, Qt sources are distributed with extensions included and unresolved by MOC. That classifies as another language used in my vocabulary – certainly C++ based one.
“OK, I know that we will not agree about this, but my credit is gone anyway, so let me get it worse a bit more:”
Your credit is not gone yet. Everyone has his opinions.
“I think that C++ code should be able to be processed by C++ compiler out of box”
Yes.
“which is not true for Qt sources”
True.
“I could agree with you about code generation if those generated files would be distributed along with Qt applications sources or if the real C++ was not in fact just intermediate product.”
I will agree that it’s not a pure C++ toolkit, because it depends on a tool to implement some functionality. But the MOC still generates C++. And C++ is not intermediate product. This is no different than some C programs that use flex. They are still C programs. I wouldn’t call them C-something.
And C++ is not intermediate product. This is no different than some C programs that use flex.
If it is not intermediate product, what is?
OTOH, flex comment is quite correct.
Maybe just boundaries between language extensions, code generation tools and new languages are fuzzy and personal.
Mirek
I think that C++ code should be able to be processed by C++ compiler out of box
Which applies to all code used in Qt applications.
You can call your compiler on any file and it will compile.
When files are being parsed by the C++ compiler, alls markup macros expand to valid C++ or are empty
I could agree with you about code generation if those generated files would be distributed along with Qt applications sources
You could do that.
In fact, since MOC is just a code generator, you can write all the code manually as well, directly into the source files, without additional generated files.
Part of the confusion is greated by calling MOC a preprocessor.
It is not, it is a code generator, which parses input files and generates output files.
For convenience the input files are regular header files and the output files are usually compiled on their own.
However, one could use separated input files, i.e. a “class” declaration only containing the code generation hints and copy the output right into the regular source file.
In this unusual yet possible case, you would not have to invoke MOC unless you change one of the generator input files.
MOC can be nicely integrated into build systems so it looks a bit like a preprocessor, however, as pointed out above, you can use it like any other code generator, e.g. parser generators.
Edit: fixed typos
Edited 2006-11-21 12:56
Anyway, more seriously, you do not have to spend more than 2 minutes with the article to find out that MOC adds significant features to C++ and that MOC++ is not C++.
There is no such thing as MOC++. Don’t know where you came up w/ that term. It’s not in Qt docs anywhere, or the linked article.
Actually moc is a pre-processor. Most of the special code in Qt is actually just normal C++ macros. moc is a preprocessor that takes your source code (standard C++ + Qt macros) and extends the classes (again using normal standard C++ language features) to add the code needed for signals + slots, etc… Hence, the resulting code is compilable by gcc, Microsoft compiler, etc… No black magic voodoo here.
Qt is not quite a C++ toolkit- it does not use standard C++
Yes it is and Yes it does. (And it’s a very tired argument. )
Qt is fully C++ all that moc does is to write a little bit of boilerplate code for you. (You could of course do it yourself, but why would you… 😉
Similar article about C++ toolkit that is in fact even much easier to use
Hmm…I must admit I do not like the style (as in capitalization/use of operators) they use. (Which of course is a subjective judment 🙂
From your article:
// Gives us a right-click menu to delete rows
arrList.Removing();
// Uses a callback to link the button to the function
btnAdd <<= THISBACK(AddItem);
EDIT: I looked at the page http://ultimatepp.org/app$ide$About$en-us.html and your profile. So you are the original author of U++?
That definitely explains your comment about being easier to use. Having written a toolkit often makes it pretty easy to use. At least for yourself.
So you try to talk down Qt to advertise your own toolkit?
Edited 2006-11-20 17:14
So you try to talk down Qt to advertise your own toolkit?
Well, in fact, I do not think that MOC makes Qt less useful. Just IMO, classifying it as C++ Toolkit is not quite correct. Therefore I do not really think that I talk Qt down.
In reality, I see reasons why they had to implement MOC years ago – C++ compilers were faulty and managing callback events by templates was not an option. So in fact, to a degree, MOC is a price for maturity.
Nowadays, it is mostly irrelevant (and I believe U++ system is better integrated with language), but they have to keep it for backwards compatibility. BTW, similar issues can be be found in other competitor, wxWidgets (www.wxwidgets.org) – they are using message maps instead, which is another solution to the same problem and they once again have to keep this forever because of compatibility. MOC is less standard than message maps but certainly much more effective.
As for other claims – yes, I am one of U++ authors, no, that codeproject article was not written by me (and capitalization is not my style – that one I do not like too). Yes, I am trying to advertise U++ at relevant places from time to time.
As for being easier to use, that claim is certainly debatable. Anyway, U++ is quite different, so why not post a link to an optional solution?
“so why not post a link to an optional solution?”
I don’t object that, being an open source solution; but “talk down” Qt/whatever from the begining to introduce another toolkit is not good maners, being you the lead developer.
Edited 2006-11-20 18:07
I don’t object that, being an open source solution; but “talk down” Qt/whatever from the begining to introduce another toolkit is not good maners, being you the lead developer.
My apologies then to the forum and trolltech, I did not meant it as talking down, just clarification.
(And I still think that my claim holds true, but that really has nothing to do with Qt usefulness).
Nowadays, it is mostly irrelevant (and I believe U++ system is better integrated with language), but they have to keep it for backwards compatibility.
I’d rather say better intergration with the language are irrelevant, compared to clearer, easier understandable and more robust code. But then again I don’t care about language purity, and prefer it not to get in the way of the real work.
U++ is quite different, so why not post a link to an optional solution?
After a quick look at the web pages for U++ it does not even look like a optional solution. The very first ting the original articles say, it’s the title even “Cross platform development for Windows and Mac OS X”. And while U++ may be a decent toolkit, it does not have support for MacOS.
It does not look like a particular good alternative for cross platform development, only support for Win32 and not fully developed on Linux. No support for other unix like os, like BSD, Solaris etc.
Edited 2006-11-20 18:17
It does not look like a particular good alternative for cross platform development, only support for Win32 and not fully developed on Linux. No support for other unix like os, like BSD, Solaris etc.
Linux is almost fully developed now (it is 6 months after last release), only finishing GTK theming integration to look native (similar to what Firefox does).
FreeBSD U++ is in ports, other BSDs work (but you have to compile from sources). All BSDs are in fact so similar to Linux that support is implicit…. Same is most likely true for Solaris, but nobody cared so far.
PocketPC is in experimental stage.
Yes, MacOS is major gap. We know that and we are working on it.
As we have quite thin system interface, we are even considering some more exotic platforms like Haiku…
As for other claims – yes, I am one of U++ authors,
good for you 😉
I imagine it is a lot of work but great fun 🙂
no, that codeproject article was not written by me
The “your article” was meant as “the article you linked”
Yes, I am trying to advertise U++ at relevant places from time to time.
Well, I am not in general opposed to that. It is always interesting to see what projects pop up everywhere. But I do like what they call “full disclosure”.
You have to admit that you are not an unbiased party, so if you make statements that can be interpreted as an attack (such as you “not quite a c++ toolkit” statement) or that contain a comparison of quality (“much easier to use“), I do not consider it correct conduct to hide the fact that you are deeply involved in the advocated project.
You have to admit that you are not an unbiased party, so if you make statements that can be interpreted as an attack (such as you “not quite a c++ toolkit” statement) or that contain a comparison of quality (“much easier to use”), I do not consider it correct conduct to hide the fact that you are deeply involved in the advocated project.
OK, learning from mistakes…
BTW, to make things clear, of all GUI C/C++/C++like toolkits I have studied intimately in past 15 years, Qt is IMO the best, except the one
…but I do not quite like the MOC and from what I have seen, I am not alone at this.
Edited 2006-11-20 18:44
…but I do not quite like the MOC and from what I have seen, I am not alone at this.
You’re missing the essential truth about using the MOC and using a preprocessor – standard C++ (or what some people see as a standard anyway) is absolute crap for getting anything done. It’s what gives C++ a bad name. This is why Trolltech actually has customers and stays in business.
I’m sure Trolltech would love to give up using a preprocessor tomorrow, but for the sake of their customers, and everybody’s sanity, they’re not going to inflict standard C++ on people.
If it has the all the pragmas or been wrapped to call from C++ then it’s a C++ toolkit whether written in pascal, lisp, or smalltalk. Additional bindings are a bonus.
moc has a big advantage over all the compile-time signal&slot mechanisms: Introspection. Look at the D-Bus bindings or the language/scripting bindings – interfacing with Qt widgets at runtime is easy. QSignalSpy even shows how to fake signals and slots at runtime.
Plus, it gives you qt_cast, the equivalent to dynamic_cast for Qt objects that reliably works through plugin boundaries.
It’s fine but it does way too much.
It was written at a time the STL wasn’t stable.
Now it sort of works with STL but you have to “translate” between the two.
The Qt paradigm tends to “borg” your application, pushing down into the program logic. IMHO that’s not a god thing, although it does lock you into Trolltech’s licensing scheme.
I’m truly amazed how long it takes to compile the basic libraries. One machine at work takes about 25mins to compile all the Qt stuff. Comparatively it takes about 1:30 (m:ss) to compile the entire FLTK2 package.
Disclaimer: At work we hold the first and second Qt license ever sold. Nowadays we write all our code entirely Qt independent with full unit test cases and everything. We pretty heavily isolate Qt so it only provides UI type things.
There’s a lot of FUD out there, so let me try to clear some of it up:
Bjarne Stoustrup was the keynote speaker last month at Trolltech DevDays. That’s a pretty big endorsement in my book!
MOC: The only native C++ mechanism for OO callbacks is function objects. They don’t give you introspection. They’re not safe (they can be destroyed, leaving a dangling callback). On the other hand, with Qt you can connect signals to slots however you want. One to many, many to one, many to many. You can even connect signals to signals!
Here’s something you can’t do with functors: specify signal/slot connections in a text file read in at runtime. That’s what I did a few weeks ago, creating a snap-together component system. There’s no way you can do this with a compile-time-only system.
What’s so wrong with the publish/subscribe pattern? That’s all signals/slots are underneath!
STL: Qt’s collections are STL compatible. You can use STL algorithms with Qt collections, and Qt algorithms with STL collections.
std::string vs QString: No contest! std::string is a thin wrapper around a char vector. QString is a full complete string class, with complete string manipulation methods, complete unicode support, copy-on-write data, etc, etc.
Exceptions: Go ahead and throw them, no one is stopping you.
My code internals don’t need internationalization.
When I want to see the condition number of the matrix I’m inverting I only need to print it out my debug in ascii. I don’t unicode for any of that. Unicode is ultimately useful for interfacing, works well on the gui side. But it doesn’t belong in my image processing algorithms.
Part of the bloat of Qt is that there are about 3+ ways to do the same thing. You may use the signal slot mechanism. If you don’t want to use that you can override the event methods from the underlying widgets and handle events that way. If you don’t like that then you can install an event filter on a widget and handle events that way. If you get too fancy with signal/slots then you end up with a signalling nightmare and issues with event tracking.
Not to mention Qt4 really bloated things by so tightly coupling everything with their MVC paradigm, especially in the Table and ListView widgets.
I mean it’s all fine, there’s a potential do lots of things, but I seriously question if all this featurization is really necessary and if it’s really worth all the baggage that comes along with it.
I will say that I haven’t really seen a good replacement for Qt yet, although I would like to spend more time with fltk2 to see if it does have enough to make it useable. I do like their KISS paradigm.
> My code internals don’t need internationalization.
famous last words
seriously though, the nice thing is that QString remains amazingly fast and light so you get this additional capability for a near zero cost.
and when you do end up needing features like i18n you don’t have to run and find a solution, it’s already there.
there are few things as annoying as running into limitations in a toolkit, particularly when fixing those limitations would not come at an appreciable cost.
of course, for your matrix code don’t use QString if you don’t want to. use std::string or even char*. there’s no one holding a QString gun to your head =)
> Part of the bloat of Qt is that there are about 3+
> ways to do the same thing
the 3 ways of reacting to events you outline each have distinct use cases and distinct times they are relevant. they aren’t the mess of overlap you suggest. i’m not sure if you’re just being argumentative or aren’t familiar with Qt, but either way you missed the mark.
> Qt4 really bloated things by so tightly coupling
> everything with their MVC paradigm
bloated in which way? API? resource footprint?
if you’re concerned about API, use the simpler Widget versions of these classes and you’re essentially back to the Qt2/3 way of doing things. if you’re concerned about resource usage, i’d suggest measuring again. for anything but trivial cases (where such numbers hardly matter one way or the other) i find the new model/view stuff to be quite an improvement here.
> if all this featurization is really necessary
of course not. it’s nice, though.
> and if it’s really worth all the baggage that comes
> along with it
imho, yes. and it seems many other qt4 users agree =)