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.

> Scribe (text render engine) and ATK accessibility bridge: now we're on par with GTK on this stuff :)

Erm, Qt is already on par with Pango.. The only thing missing for a while was proper Indic support which came out in Qt 3.2. Qt 3.0 had bidirectional-text support months before Gtk 2.0 came out (with Pango), and Qt 2.0 came out with full fledged Unicode support, many years before Gtk 2.0 and Pango had that.

Actually not quite. Pango deals with fonts better on linux, especially a lot of those in the cjk range. It also has a text layouting api that qt desparately needs, to handle complex line breaking and paragraphing situations.

Also, support for input methods in qt is lacking, as qt3 only really supports XIM.

> It already has a complex text layouting API since Qt 2.0. It was mostly rewritten in 3.0 to support bidirectional text.

Is it a public API? Last time I checked, things like QTextEdit could do it right, but when it came two writing your own widgets that needed layout, there wasn't much of a way to do it?

Also, which input method plugins were you referring to? THe only thing I know about is the 'immodule for qt' effort, but it hasn't been incorporated into qt and as far as i know there hasn't been much mention of it outside of the pages and mailing lists that are directly associated with it.

However, concern about these advanced features is misplaced because the current release of Qt does not handle fonts well -- basic font handling. It fails to find a significant number of my installed fonts which even WordPerfect-8.1 finds correctly.

Test case: I have several weights and widths of Helvetica (Type1) which are simply not listed. What is worse is that this (to some extent) is a regression. I am certain that I used to use Helvetica Narrow with no problem.

Yes, I did send them a bug report and the advised me that my analysis of the problem was correct (TrueType and Type1 handle this differently) and that they would work on it.

With other fonts, Qt does find the font, but it then uses the wrong font. Considering that Qt is now in version 3.x.y this causes great concern -- in general problems like this are usually due to a naive design.

I hope that at least some of this gets fixed with 3.3.2 -- if I had paid full price for these fonts, I would not be very pleased that I can't use them in KDE.

The new foreach is most probably a macro (and it will probably expand to suboptimal code (say "const vs. non-const iterators").
If it was more than that, you wouldn't need the redundant "QString s" declaration in it ("list" already has that information), so you could write:

foreach( s, list )
len += s.length();

The problem I see is that "foreach" - as an identifier - will surely clash with a possible future C++ reserved keyword of the same name. But then, the C++ people will more likely standardize the Boost Lambda library than introducing syntactic sugar in the language...

Actually, with our version of foreach you can write both. foreach(s, list) works just as well as foreach(QString s, list). It is a combination of template magic and a macro. The macro is of course called Q_FOREACH, but you can set a flag that "pollutes" the namespace with the foreach keyword if you want to.

The code it expands to isn't exactly trivial, especially not on non-gcc compilers like MSVC6. The generated assembly, however, is pretty optimal. While it is slightly bigger than a handwritten loop, there is basically no speed difference.

Would I recommend the construct to someone who knows and loves the STL? No. Would I recommend it to somebody who wants to write readable, fast-enough, and good-enough code and possibly has a Java background? Yes. Do I use it myself? In application code, yes.

"Would I recommend the construct to someone who knows and loves the STL? No. Would I recommend it to somebody who wants to write readable, fast-enough, and good-enough code and possibly has a Java background? Yes. Do I use it myself? In application code, yes."

I am quite a bit curious: Did Trolltech implement this via the moc preprocessor? If not, I can hardly imagine a way how this can be done with pure C++ and general enough so that user defined container classes will work with this. I came up so far with the snippet below, but this has its limitations as can be seen.

Eric Niebler submitted an implementation of a FOREACH macro to boost that was really clever. It has since been yanked. Here is the readme:

BOOST_FOREACH
by Eric Niebler

The BOOST_FOREACH macro is a simple, intuitive and typesafe way to iterate
over a collection. It is inspired by similar looping constructs in other
languages, particularly C#. It is intended for inexperienced programmers who
do not know much about iterators, predicates and half-open sequences. It is
also useful for anybody who wants to type fewer characters when writing loops
over sequences. Its salient features are:

- It works over STL containers, arrays and null-terminated strings.

- Your loop variable can be a value or a reference. If it is a reference, then
any changes you make to it get written through to the underlying sequence.

- It generates near-optimal code. That is, it is almost equivalent to the
hand-coded equivalent.

- It behaves just like a for loop. That is, you can break, continue, goto or
return out of the loop body.

Many of the ideas for BOOST_FOREACH are described in the Nov 2003 C/C++ Users
Journal article by myself and Anson Tsao. That article describes how to
implement a FOR_EACH macro that works with .NET collections. BOOST_FOREACH is
a reimplementation of the original FOR_EACH macro that works with native type.
It also corrects a number of shortcomings of that implementation.

"Driven by consumer electronic devices such as mobile phones and PDAs, desktop applications are moving away from standard widgets and styles towards more customized user interfaces"

While I'm glad Qt 4 will have a better style engine, and that it will better support miniscule low-bit displays on phones and devices, isn't this another word for "skins"? And aren't the current Qt style preferable to bitmapped skins? I don't want my KDE desktop looking like an LCD display. Nor do I want it looking like something Nullsoft drew.

OK. I love the look of the Qt iterators. One big thing I dislike about C++ is the STL. It is soooo ugly. C++ is an inherently ugly language, but at least Trolltech are doing their best to make it useable. Just compare:

Once you remove the template (and casting) syntax, C++ isn't ugly. Quite the opposite. It makes a readble and easy-to-write language. But only if you stay away from that awful template (and casting) syntax.

I must disagree. I find C++ to be ugly. It's a bolt-on to C, with a bunch of other bolt-on features. It's too hacky for my tastes. For example, why not make a sane syntax for abstract classes, such as
abstract class Foo;

Instead, you can choose to set a method equal to zero (hello, what? does this make any sense at all?) or make the constructor private (makes more sense, but still not as clear, to me, as an "abstract" keyword).

I'm not saying that C++ is the world's crappiest language, but it's far, far, far from elegant. ESPECALLY, as you point out, when you add templates.

Languages, such as Ruby, that were designed from day one with OO in mind are much cleaner to work with. Now all we need is a Ruby compiler.. :(

The template mechanism is one of THE reasons why C++ is THE language especially for high-complex numeric problems since it provide the capability to write complex but very performant programs. There is no substitution for this in any other language. Beside this, I won't miss any of the other features C++ provides. See the Java-guys: they try to integrate all these C++ features the'd called "depreached" like enums and other. IMHO Java has more structural disadvantages as C++. One of the biggest disadvantage is thatyou have to call new every time you want to instance an object.

I agree with the other poster. Templates in C++ are an ugly preprocessor hack. It is a bit like operator overloading, the arguments for why operator overloading in C++ is so good always involve either complex numbers or matrix math...

But this is technically not the same as the other examples. It would be trivial to implement this in C++ via a macro. The reason why your example is different from the others is that it will only work with containers which have an subscript operator. It will not work with containers which can only be forward traversed.

>Is:
>sum([len(l) for l in list])
>Really easier to read than the *idiomatic* perl equivalent:
>$sum += length for @list;

not if you are already a perl programmer. yeah, I do not really like the way it reads. what are these extra characters, '$', '@' and ';'? I think I would prefer 'sum += length for list', that really is easier to read. you know that working memory is limited, and having all sorts of redundant characters on a line (especially one longer than this) makes it harder to read. then, the '+=' turns me off a bit. it just seems awkward, but also for beginners and for e.g. presenting code to a math professor it's not very readable. in Python you tend to 'transform' datastructures, so you don't need awkward constructions like this. I admit the Python expression isn't insanely obvious at first, but at least once you get it it reads easily, and it's not awkward at all. it just says what you want to do, almost literally: 'I want the sum of the lengths of the things in this list.' what does the perl version say? 'I want to += the length for this list, and it's not clear what $sum is, initially.' and how flexible is this perl construct? can I add for instance the numbers of two lists? in Python this would be [a+b for (a,b) in zip(l1,l2)]..

But you have to know a little of any language before using it properly don't you:

$= scalar, @ = array, % = hash etc. Most of the other punctuation marks rarely have to be used or have English equivalents.

>but at least once you get it it reads easily, and it's not awkward at all

That's the whole point isn't it - once you get most (though not all :) languages they read easily! It's sad that much of the code posted by people to show how bad perl is often isn't idiomatic perl - it wouldn't take me long to write some hideous python, ruby, tcl, Java, C# etc code because I'd only have a relatively superficial knowledge of them.

> 'I want the sum of the lengths of the things in this list.' what does the perl version say?

You're being silly now - it says "sum the length of each item in this list". There's really not much difference here - they're both clearer than many other languages!

> it's not clear what $sum is, initially

Eh?

>in Python this would be [a+b for (a,b) in zip(l1,l2)]..

Yes, there's no doubt that's a nicer way than a perl equivalent - that's why zip is being introduced in p6. There's some great stuff in python, and p6 will certainly show some influence from python, but the fact remains I find it amazing that people are quick to judge other languages when they clearly have little knowledge of them.

I'm not implying you, rather the original posters of the perl examples.

I respectfully disagree with your statement, that most languages have the same readability, once you are used to using them. by readability I mean a lot of things, like: is a language orthogonal, so that different programmers can quickly understand each others code? is it compact yet still clear, so that you can see what is happening from a high level? does it do away with low-level details irrelevant to the essence of what you are doing? can you re-read your code again after having worked on something else for six months? is the code accessible to beginner (or new at the project) programmers, so they can easily add or change things? I think these, among other things of course, all contribute to the inherent 'readability' of a language. not to make this into a python-perl war, looking at it this way, I think it is safe to say that Java is more readable than C. I also think Python is more readable than Java, because you can do a lot more in much less lines, while still being perfectly clear as to what is happening. I think the addition of all sorts of more or less redundant characters in Perl (I forgot ';', '{' and '}' :-)) makes it a little less inherently readable.

but I admit I was probably overreacting a little.. Perl and Python are both great languages, and they are a lot more alike than that they differ..

Although doesn't look any more readable than the python to me - they both look just fine!

But ruby blocks and iterators are certainly very nice - I don't know if python works the same. Does it allow you to yield multiple values from a block? In ruby the little expression above is actually a sort of co-routine where the block and the Array yield control to each other for each iteration.

so printing out the sum takes three lines..? yes, Python also has multiple return values (I do not understand how a ruby block works?), a general iteration protocol, and yield statements that allow functions to temporarily return and later resume what they were doing.. I don't thnk there are big semantic differences between perl, ruby and python. it's mainly the syntax..

I think yield is a bit easier conceptually to understand if it's viewed as an invocation of a closure and not a co-routine transfer, since IIRC, the block can just return, and not transfer back, no? (Although the co-routine definition certainly matches the history of the yield keyword), particularly considering the roughly interchangeability with Proc/Lambda

It's compositional and perfectly orthogonal; it involves two concepts (blocks and methods) which are found in every single program all over the place. It's just passing a code fragment to the .each method of the list, to call on every element. It does not need a special syntax to construct a new list of values by iterating over an another list, which I am guessing the Python example is doing. Also, as a matter of my own personal preference, the Ruby example follows a hierarchical structure of control flow, where outer control statements are on the outside in the code (yes, I never uses the postfix forms of if or unless in Ruby code)