Linked by Eugenia Loli on Mon 20th Nov 2006 16:31 UTC, submitted by elsewhere
Qt "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.
Order by: Score:
v Not a C++ toolkit...
by luzr on Mon 20th Nov 2006 16:46 UTC
RE: Not a C++ toolkit...
by sbenitezb on Mon 20th Nov 2006 16:53 UTC in reply to "Not a C++ toolkit..."
sbenitezb Member since:
2005-07-22

"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

Reply Score: 5

RE[2]: Not a C++ toolkit...
by luzr on Mon 20th Nov 2006 17:00 UTC in reply to "RE: Not a C++ toolkit..."
luzr Member since:
2005-11-20

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

Reply Score: 3

RE[3]: Not a C++ toolkit...
by sbenitezb on Mon 20th Nov 2006 17:03 UTC in reply to "RE[2]: Not a C++ toolkit..."
sbenitezb Member since:
2005-07-22

"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?

Reply Score: 5

RE[4]: Not a C++ toolkit...
by luzr on Mon 20th Nov 2006 17:53 UTC in reply to "RE[3]: Not a C++ toolkit..."
luzr Member since:
2005-11-20

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

Reply Score: 1

RE[5]: Not a C++ toolkit...
by sbenitezb on Mon 20th Nov 2006 18:14 UTC in reply to "RE[4]: Not a C++ toolkit..."
sbenitezb Member since:
2005-07-22

"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

Reply Score: 5

RE[6]: Not a C++ toolkit...
by luzr on Mon 20th Nov 2006 18:22 UTC in reply to "RE[5]: Not a C++ toolkit..."
luzr Member since:
2005-11-20

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.

Reply Score: 1

RE[7]: Not a C++ toolkit...
by sbenitezb on Mon 20th Nov 2006 18:34 UTC in reply to "RE[6]: Not a C++ toolkit..."
sbenitezb Member since:
2005-07-22

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

Reply Score: 4

RE[7]: Not a C++ toolkit...
by anda_skoa on Tue 21st Nov 2006 12:49 UTC in reply to "RE[6]: Not a C++ toolkit..."
anda_skoa Member since:
2005-07-07

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

Reply Score: 2

RE[3]: Not a C++ toolkit...
by Latem on Mon 20th Nov 2006 17:08 UTC in reply to "RE[2]: Not a C++ toolkit..."
Latem Member since:
2005-07-06

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.

Reply Score: 5

RE: Not a C++ toolkit...
by camel on Mon 20th Nov 2006 17:03 UTC in reply to "Not a C++ toolkit..."
camel Member since:
2005-06-29

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

Reply Score: 5

RE[2]: Not a C++ toolkit...
by luzr on Mon 20th Nov 2006 17:42 UTC in reply to "RE: Not a C++ toolkit..."
luzr Member since:
2005-11-20

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?

Reply Score: 4

RE[3]: Not a C++ toolkit...
by sbenitezb on Mon 20th Nov 2006 18:07 UTC in reply to "RE[2]: Not a C++ toolkit..."
sbenitezb Member since:
2005-07-22

"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

Reply Score: 1

RE[4]: Not a C++ toolkit...
by luzr on Mon 20th Nov 2006 18:10 UTC in reply to "RE[3]: Not a C++ toolkit..."
luzr Member since:
2005-11-20

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

Reply Score: 1

RE[3]: Not a C++ toolkit...
by Morty on Mon 20th Nov 2006 18:16 UTC in reply to "RE[2]: Not a C++ toolkit..."
Morty Member since:
2005-07-06

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

Reply Score: 4

RE[4]: Not a C++ toolkit...
by luzr on Mon 20th Nov 2006 18:31 UTC in reply to "RE[3]: Not a C++ toolkit..."
luzr Member since:
2005-11-20

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

Reply Score: 2

RE[3]: Not a C++ toolkit...
by camel on Mon 20th Nov 2006 18:19 UTC in reply to "RE[2]: Not a C++ toolkit..."
camel Member since:
2005-06-29

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.

Reply Score: 4

RE[4]: Not a C++ toolkit...
by luzr on Mon 20th Nov 2006 18:35 UTC in reply to "RE[3]: Not a C++ toolkit..."
luzr Member since:
2005-11-20

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

Reply Score: 1

RE[5]: Not a C++ toolkit...
by segedunum on Mon 20th Nov 2006 22:42 UTC in reply to "RE[4]: Not a C++ toolkit..."
segedunum Member since:
2005-07-06

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

Reply Score: 5

Way to beat a point to death guys
by Sphinx on Mon 20th Nov 2006 17:14 UTC
Sphinx
Member since:
2005-07-09

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.

Reply Score: 3

why you can't live without moc
by harryF on Mon 20th Nov 2006 19:29 UTC
harryF
Member since:
2005-07-06

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.

Reply Score: 5

Some comments
by bnolsen on Tue 21st Nov 2006 04:56 UTC
bnolsen
Member since:
2006-01-06

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.

Reply Score: 2

Clearing up some FUD
by Brandybuck on Tue 21st Nov 2006 07:22 UTC
Brandybuck
Member since:
2006-08-27

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.

Reply Score: 5

RE: Clearing up some FUD
by bnolsen on Tue 21st Nov 2006 15:31 UTC in reply to "Clearing up some FUD"
bnolsen Member since:
2006-01-06

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.

Reply Score: 2

RE[2]: Clearing up some FUD
by aseigo on Tue 21st Nov 2006 16:41 UTC in reply to "RE: Clearing up some FUD"
aseigo Member since:
2005-07-06

> 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 =)

Reply Score: 5