Qt Quarterly is a paper-based newsletter exclusively available to Trolltech's Qt customers. As a courtesy and convenience, a selection of articles are delayed also made available online in HTML format. One of the more interesting articles for KDE developers in this year's first quarter issue is an article by Jasmin Blanchette which gives "A Taste of Qt 4". A Qt 4 technology preview is expected for this summer requesting for feedback and a Qt 4 Beta is planned for the second half of 2004.

I find OO to be clearer in cases like this. You ask the list to give you each element in turn. Since each element is an object, you can pass messages to them.

It's not that I find the Python *terrible*, but I think the Ruby just makes a lot more sense. I also get sick of statements like "is the thing that pops right into your head when thinking about the problem.. right?"

Bing! we have a winner. The simple clarity combined with brevity of this solution is beautiful. I was looking at the list comprehension solutions, and fiddling around with my own... then saw this. And saw the light.

The only part that looks slightly cryptic to a non-Python person may be the map(). But that's okay.

I also find it interesting that while python has the slight reptuation of being more rigidly structured that certain other languages, so many very different Python solutions were given here.

For one, you could use it->length() instead of the (*it).length();
For two, if you allow Qt to use non-std-c++ tools, let me show you how the same code looks using lambda functions (from the Boost library, the playground for libraries that are proposed for inclusion in the next C++ std version):

The best thing here is that this is void of redundancy (cf. "QString s" in the Qt foreach). You might wonder why I have to give the seemingly redundant list.begin(), list.end() here, after all "list" should just do, right?

You are free to write a small wrapper around std::for_each() that does exactly that. But the begin/end concept allows the algorithm to work on any range, e.g. this one:

So if you say that C++ is an ugly language b/c of the STL, then let me respond by telling you what the STL is all about. It's about removing redundancy. As with desgin patterns, once you start thinking in algorithms instead of implementation, you are able to tackle more complex problems. In this case, note how we can change the value_type of the containers without changing a single line of the algorithm code. Can't be done with Qt4's foreach(), which is even worse than the full-length STL example they gave, since you can always use "typedef QList Container" to hide the value_type, whereas Qt's foreach _requires_ you to explicitly state the value_type for _every_ for loop. Note also how in the accumulate() example, we said _what_ we do instead of _how_ we do it :)

It's of course easy to make a special case look better. This reminds me of the wannabe physicists that regularly write papers that seemingly convincingly disproof the Einstein theory of relativity. But if you look closer, they pick a single prediction out of the vast array of predictions of the full theory and found another explanation for that since prediction. That their "theory" (in contrast to Einstein's) fail to explain all the other effects that man observes in the universe isn't relevant to them.

Same here. The STL tries to relieve you from writing for loops. for_each() is just one of many STL algorithms. It doesn't matter that you have found a nicer syntax for a for loop if the real goal is to avoid writing them out explicitly in the first place :)

Oh, yes. I used QValueVector, where it works due to the iterator being value_type*. Which is another problem with Qt containers. They use lists all over the place, where a vector would suffice, and probably yield better performance (less malloc()s, for one). Just look at the implementation of operator[] for QValueList - ugh. (hint: QValueListPrivate::at())

So if you say that C++ is an ugly language b/c of the STL, then let me respond by telling you what the STL is all about. It's about removing redundancy. As with desgin patterns, once you start thinking in algorithms instead of implementation, you are able to tackle more complex problems. In this case, note how we can change the value_type of the containers without changing a single line of the algorithm code. Can't be done with Qt4's foreach(), which is even worse than the full-length STL example they gave, since you can always use "typedef QList Container" to hide the value_type, whereas Qt's foreach _requires_ you to explicitly state the value_type for _every_ for loop. Note also how in the accumulate() example, we said _what_ we do instead of _how_ we do it :)
--

That's nice. The STL and C++ are still ugly. The claim wasn't that C++ is a useless language. It's that C++, and the STL are ugly. You'll never convince me otherwise, simply because in my opinion, they're not fun to look at.

Readability is king, because reading code is much more time consuming than writing code! (even though trying to find way to l33t-STL-encrypt a simple loop can indeed cost more time ;)

I guess that's also why foreach (just like C#'s foreach, btw) requires the type of the loop variable. Plus it's perfectly consistent with for and while.

And talking about redundancy: The 'var' is redundant. Unlike the type in the foreach it adds no value when reading the code.

Try teaching a freshman from university the magic of _1, ref(), var() and constant() versus the simple foreach in the example. It becomes much more fun, btw, if next to the _1 a 1 as constant appears - goodbye readability.

STL is not necessarily a good argument when trying to convince for example a C# or Java programmer to use C++ for his next project.

When I first read it I thought: Ok, this adds 'sum' to each element of the vector v.... Wait, that wouldn't make sense. Ok, so I need to look up what exactly 'add_to' does. *browses possibly external header file for definition, while breaking the flow of reading code*

Trolltech is so great. Qt4 looks just awesome. I'm particularly happy about the vector drawing engine (Arthur), and the new Interview system. It looks like Qt will remain one of the most powerful toolkits out there. If Qt4 is as good as its shaping up to be, it'll also quiet down any nay-sayers who think Longhorn will leave *NIX GUIs behind the technology curve.

The nay-sayers won't shut up. It's their hobby to ridicule the NIX desktop. I suspect that in ten years, when KDE has 62% of the desktop and Windows with a paltry 3%, they'll still be saying "but wait until the next release!"

"It's their hobby to ridicule the NIX desktop. I suspect that in ten years, when KDE has 62% of the desktop and Windows with a paltry 3%, they'll still be saying "but wait until the next release!""

Well let us not get ahead of ourselves :). However, I'm using .NET now commercially, and although it is certainly an improvement on Win32 programming (C# is a very nice language) there is a heck of a lot in the NIX/Qt world that completely nullifies any hype. Rest assured that there is nothing in .NET/WinFX that you can't do just as easily using Qt and NIX based technology - quite the opposite infact :).

Qt 4 sounds amazing, I just hope that they will be able to deliver, that's a hume amount of stuff their promising and none of it is trivial. I'm very happy with the direction Trolltech is taking with Qt 4 and I wish them the best of luck!

I'm also looking forward to Mark Summerfield and Jasmin Blachette's book on Qt 4.0. I've already got their book on 3.2.x and I found it to be pretty good, though still a bit too advanced for me (I don't know C++ well).

"In Qt 3, Qt Designer and Qt Assistant are used independently of the programming environment. Starting with Qt 4, it will be possible to use these tools from within the programming environment. Initial plans are for integration with the Visual Studio .NET, KDevelop, and Xcode IDEs."

Yes, very important. I think at the moment people are a bit mystified with using two or three development environments. With VB/VC++ etc. Microsoft learned the wisdom of binding things together.

"A new paint engine...A new text-rendering engine"

This sounds like a premier platform to do Office suite development on....

"The new model/view framework, codenamed Interview, provides tree views, list/icon views, and tables using a common data model abstraction to support data-driven GUIs that are fast and responsive even with large data sets."

Spot on! People moving from a Windows environment and really developing commercially will certainly appreciate this.

"Qt 4 introduces a new set of template classes, codenamed Tulip, that are lighter, safer, and easier to use than the STL's containers. Developers who are unfamilar with the STL, or who prefer the "Qt way" of doing things, can use these new classes instead of the STL classes."

This sounds great, although I will say that if you are going to do this with C++ why not use a language like C#/Java etc. in the first place? They are languages that syntactically look much better when doing stuff like this.