MAY
12
2004

Qt Developers Conference Report

On May 10th, ICS presented a Qt Developer
Conference
in Waltham, Massachusetts. Over 100 developers were on hand to
hear presentations from Havaard Nord (TrollTech CEO), Jasmin Blanchette
(TrollTech uber-developer) and Matthias Kalle Dalheimer (Klarälvdalens
Datakonsult CEO).

It was a somewhat uneven conference. There were some great technical
talks and then there were some that were too high-level and slow moving.
Jasmin Blanchette did not have enough time for his talk on Qt 4, causing him
to rush and leaving little time for Q&A. Havaard Nord's talk on the soul of Qt was inspiring and included some interesting results from a
recent customer survey. A low point was probably the talk on GUI design, which
really had nothing specific to Qt. This time would have been better spent
having Matthias Kalle Dalheimer demonstrate KD Executor, which was very
popular during the breaks. Joe Longson (from Walt Disney) demonstrated an
amazing Qt application that Disney uses to manage production of animated
feature films. Gregory Seidman's talk on using a app-global relay object
(publish/subscribe pattern) to centralize connecting signals and slots was
very useful.

As of this writing, I could not find an online version of the speakers'
slides, but I believe ICS intends to post
them.

TrollTech Customer Survey. Havaard Nord's presentation included data
from a March 2004 customer survey. The survey was sent to 6,000 licensees and
had a 25% response rate. Some of the results:

  • The most commonly used modules is threading (50% of responses). So we
    can expect TrollTech to focus on threading module.
  • GNU/Linux and Mac OSX are growing fast (see table below).
  • Only 31% of respondents have participated in an Open Source project. (2%
    didn't know if they had or not! :)
  • 97% would recommend Qt to others

Target OSNowPlanningChange
Mac OSX14%25%79%
Windows 200313%19%46%
GNU/Linux67%72%21%
Windows XP71%65%-9%
Windows 200070%53%-24%

Licensees where asked what OS they are targeting now and what OS they are planning to target. While this table is based on the 1,250 responses TrollTech got, it is not
clear if all 1,250 responses answered this question, nor was any attempt made
to quantify the customer base of each respondent. So take these results with
a grain of salt.

Qt 4.0 An article in the recent
issue of the Qt Quarterly has a list of the changes coming in Qt 4 (pronounced
"cute four"). TrollTech developer Jasmin Blanchette, co-author of the recent
TrollTech/Prentice Hall Qt book, gave a great talk on Qt 4. Some things that
stuck out for me from the talk:

  • MVC. The list, tree and table views have been refactored
    to use a model-view-controller pattern. The model data structure (a tree
    where each leaf has columns) is the same for all views, so your data can be viewed with a 1D list,
    2D table, or 3D tree. The API is now consistent across all three.
  • Threading. Signals and slots now work across threads. Container
    reference counting is now thread-safe, so you no longer need to use QDeepCopy.
  • Containers. All containers (for example, QList, QLinkedList,
    QVector, etc.) are now value based. QList is the container of choice in most
    cases. But use an integer to scan the list, as iterators are not guaranteed
    to be valid if you change a list while interating over it's contents.
  • Performance. A lot of work was done reducing memory allocation to
    improve performance. QStrings and QByteArray used to require two mallocs for
    each instantiation. They now require one. QList is now much smarter about
    mallocs; for example, if you are working with a list of pointers, it does not
    allocate a pointer to the pointer, it uses the existing pointer. Another area
    where mallocs were reduced is in the object hierarchy. In Qt 3, if there were
    three parent classes to the object you instantiated, four mallocs
    occurred--one for each class in the hierarchy. Now there is just one. These
    changes (particularly the QString change) result in huge differences; for
    example, the memory allocated at Qt Designer start-up was reduced by 46%!
    Designer now starts almost twice as fast in Qt 4 as it did in Qt 3.

A alpha / developer-preview release of Qt 4 is planned for May or June of
2004.

Comments

One thing I'm very interested in knowing about is the possibility of a C#/.NET implementation of Qt. I'm no fan of Microsoft, but the more I look at .NET, particularly Mono, the more I become convinced of it's potential. My biggest hope out of the conference was the announcement of Novell purchasing Trolltech or at least special rights to Qt and porting it to Mono. This of course didn't happen, but I still hold out hope for either Novell coming to their senses that this is the route to take OR Trolltech deciding to explore porting Qt themselves (which I'm sure they've done some of). Was there any hints of this or buzz among attendants?

Eron


By Eron Lloyd at Wed, 2004/05/12 - 5:00am

I didn't hear much discussion of .NET/Qt. Someone did ask if Qt was going to support things like Avalon / Longhorn (whatever that means) and the answer was yes.


By mbucc at Wed, 2004/05/12 - 5:00am

Mmm. In what way? Is this Longhorn only?


By David at Wed, 2004/05/12 - 5:00am

What would it buy you? The point of C#/.NET is the integrated development environment, especially the framework. If you have the .NET framework there is no real need for a second framework (Qt). It just causes unneccessary troubles, and there are no features in Qt that are not also provided by .NET.
And once XAML is available (or if you use one of the XAML clones which are available now), Qt4 does not look very competitive...


By AC at Wed, 2004/05/12 - 5:00am

IMHO it would offer a better language to develop in, firstly. C# seems much more elegant and consistent than C++, providing garbage collection, better exception support, much more OO container types, etc. Don't think of .NET as one monolithic system... the libraries of the CLR alone with the improved syntax of C# could make Qt development much more pleasant. Plus, the CLR includes many useful libraries that make me turn to Python usually, like math, XML, networking, and cryptography. Even if Qt provides a lot of overlap to the CLR (like it does in PyQt), the fact of not having to use C++ alone is very appealing. Qt is having to provide a lot of this anyways (look at Qt's STL replacement types, properties, data access, runtime introspection, etc), so it should move to a more modern platform to provide these capabilities at a lower-level. I suppose the biggest appeal is using Qt instead of GTK+ to provide the GUI facilities under Mono. That coupled with Trolltech's fantastic documentation standards...

Wishful thinking, I suppose.


By Eron Lloyd at Wed, 2004/05/12 - 5:00am

What is it that is so fantastic with C#? I've heard a lot of times that C# is Java done right, without any futher explanations. What is it that is so right about C#? To me it looks like C# is as different from Java as Java 1.4 is to Java 1.5.
By the way, when will XAML, which so far got support for rotating a widget in realtime (given you have a 6GHz computer), be able to compete on any other platforms than Longhorn? As far as I know, QT runs on anything that's got a processor, It looks completely consistent on my KDE desktop which is a lot more than you can say about any MS product. My MS office package looks completely different from my Internet Explorer and not to mention 3rd party software, which looks like it runs by accident. This is the same on all versions of Windows.
What is there to compete with? QT is already Superior.


By Vegard Figenschou at Wed, 2004/05/12 - 5:00am

You have to remember that Qt is a framework, whereas C# is a language. What can be done is an implementation of Qt *in* C# to provide a better alternative than C++.


By Eron Lloyd at Wed, 2004/05/12 - 5:00am

It is very unlikely that Qt will be reimplemented in C#, as there is so much code that depends on it. This is arguably a good thing. Contrary to the hype which is around C#/.NET these days, you never hear compelling advantages of C# over C++. You often hear garbage collection, which is available for C++ too, and you hear properties which are, first, of dubious value and, second, available with C++ if you use QT too. On the other hand what is missing from C# is eminent, just some examples:
Support for generic programming is weak, and "generics" are planned first for C# v2.0. By consequence, generic library components are inferior.
There is no Support for "real" RAII, garbage collection is forced on you.
There is one unnecessary base class for every type.
There is no multiple inheritance (probably only a minor point).
There is no standardized preprocessor.

I do not want to let it sound as if C# was a complete catastrophe, if you do like the language it is of course you choice to use it (use, however, a free implementation). But do not try to fool others into thinking that C# is better than C++. If you have something you do not like about C++, say specifically what it is (and check if the next version of the standard will probably have it).


By El Pseudonymo at Wed, 2004/05/12 - 5:00am

Well, people are already trying (bindings, anyways). That there are no compelling features of C#, I found this article to catch my attention: http://genamics.com/developer/csharp_comparative.htm#27

I know some GC support is available for C++, but like most things, seems tacked on as an afterthought. And how do you mean that GC is forced upon you in C#? For properties, I see this as important; in fact, you'll notice Qt 4 moving more to properties itself.

Qt itself sports a base object, QObject, which has real and important functionality. Qt also only support single-inheritance models, so how would that hurt if using C# as well? Usually multiple inheritance is only good for mixins, whose need can be removed with a well-designed class structure (again, see Qt itself). I just don't see the arguments.

I suppose I just see C++ as slow-moving (improvement-wise) and past its prime.
Sometimes it is better to start all over again. Perhaps if someone could point out all the exciting things C++ is planning to offer I'd change my mind. Because C# doesn't support this or that yet doesn't convince me. The language is still quite young and new stuff is being added at a good pace (similar to the pace Python adds language and API changes). With Mono in the mix now adding value to the current implementation and extensions to mscorlib.System, there should be some competition (hopefully).


By Eron Lloyd at Wed, 2004/05/12 - 5:00am

I aggre with El Pseudonymo, that C# is not that much better than C++.

a) In an OO world memory management ist way easier than in the procedural world. additionally to GC smart pointer can provide a safe and fast solution.

b) not all classes in Qt are derived from QObject.

c) C++ may have a few dark corners, but on the other hand you get seemles interoperability with C libraries, which is a big plus especially in the Unix world that seems to be stuck in the C-ages

d) a new c++ standard is supposed to be out in 2005(introducing GC), 2002 was the ABI standardisation, 1998 was ISO standardarsation. so there is stuff going on. For a language of the importance of C++ you just cant change things all the time.

e) many things are being developed in libraries instead of the language, which fits into the philisophy of C++ being low overhead. I wouldnt call Qt slow moving ;)

Marc


By Marc at Thu, 2004/05/13 - 5:00am

a) Smart pointers and constructors/destructors make memory management certainly easier but still not as easy as with garbage collection, while smart pointers introduce overhead that is comparable to GC, while often only providing partial solutions to automated memory management. Also memory management of shared resources with constructors/destructors is as cumbersome as in C. You have to be careful with your interface if the class handles all memory by itself or you delegate responsibility to a client which is dangerous. The .NET garbage collector is well integrated and you don't need to use some special syntax, something which cannot be said of most C++ GCs. The design can focus on algorithmic challenges instead of worrying about proper memory handling.

b) I consider a common base class a good thing(TM).

c) Interoperability with C libraries is well handled in most higher level languages. Take Python for example which provides many bindings to C libraries. .NET also allows easy interoperability with legacy code via P/Invoke.

d) The ISO C++ standard won't introduce GC AFAIK. What you are referring to is the C++/CLI integration that is on a separate ISO track (while some of its members are also taking part in ISO C++). In fact C++/CLI is a targeting C++ to the CLI (which is a subset of .NET) thereby introducing GC as well. However if you consider this as a good development I don't understand the critique of .NET/C#. Besides I agree with you that C++ is (slowly) evolving and there are reasons tor the slow pace. Anyway C++ is falling behind in terms of features and the legacy burden forces lots of questionable syntax extensions making the complex C++ even more complex.


By Anonymous at Fri, 2004/05/14 - 5:00am

a) smart pointers do not cause the same overhead as a GC, because in case of smart pointers there is only overhead for the objects managed by a smart pointer, while with GC _ALL_ objects have GC overhead even if they dont need it.

b) Not always you want to derive every class from a heavywheight Object class if you dont need the extra functionality. Why should QChar for instance derive from QObject? Just imagine what kind of overhead that would be for the QString class!!!

c) In C++ you can use C libs directly, without any wrappers, or special C API's. P/Invoke is probably not as complicated as Pythons C API or Javas JNI.

d) Garbage collection is planned to go in the ISO standard. Even Stroustrup is ok with that. But you will be able to switch it off, of course. Btw, my critique wasn't that C#/.Net is a bad language, I just said its not that much better than C++.


By Marc at Fri, 2004/05/14 - 5:00am

a) Sorry for stating my point not clear enough. What I wanted to point out is that GC is no more slower or inefficient than most semi automatic memory handling or even than completely manual memory handling. You may want to refer to Hans Boehm's web site and the articles mentioned there.

b) .NET still allows you to create and use efficient types. Read something about boxing/unboxing on the net. I can treat an int simply as an integer value type (one that's sizeof() returns 4 byte) and as an object if I box it (often implicit). As long as I simply use it as an integer there is no overhead involved.

c) P/Invoke is certainly not complicated but easy to use and straightforward. Microsoft had to ensure that the transition from legacy code is not to painful since it wanted to attract lots of developers.

d) GC in ISO C++ is new to me. Need to check this out.


By Anonymous at Fri, 2004/05/14 - 5:00am

I am not sure what people mean when they say that C# has no compelling features. It seems to me that people are confusing the runtime environment of .NET and the language C#. C# is a *nice* language, but currently the only way to run C# is on top of a virtual machine with all the associated overheads (extra memory for VM instantiation, runtime checks, etc). Many of the things that people say are great/bad about C# are in fact properties of the .NET runtime, not the C# language. I'm sure if somebody made a native compiler for C# that used the QT libraries, people wouldn't complain so much. In fact, it seems as though that's exactly what Trolltech is moving towards with moc and language extensions such as the "foreach" construct.

Likewise, the implication that C++ is "slow-moving" is quite meaningless. Once again, are they implying that the language should evolve faster or the platform? QT is moving quite rapidly (as observed) and making very interesting strides comparable to .NET. C++ is a fairly mature language and IMHO *shouldn't* radically alter itself every two years.

As for platform niceties such as GC (that QT currently doesn't offer) and runtime security checking, it is true that VM platforms such as Java and .NET offer a more integrated environment. However it is arguable that such things can be added into a platform without all the associated overhead of a virtual machine environment through a combination of static analysis and conservative collectors. Basically, I believe it is important for people to

1) Separate the language and platform when talking about things like C++, QT, C#, .NET, etc
2) Realize that just because something runs on top of a virtual machine doesn't make it better


By James Horey at Thu, 2004/05/13 - 5:00am

I think right the first point on the page you mentioned illustrates what I mean: There are many restrictions ("No concept of inheriting a class with a specified access level", "No global functions or constants, everything belongs to a class"), and there are "improvements" on C++, whereas in C++ the feature is actually there like thread support.
So you have some real improvements but you have quite some deficiencies. So my opinion remains, changing to C# is no real advantage.


By El Pseudonymo at Thu, 2004/05/13 - 5:00am

There are *not* many restrictions in C#. There are some features (access specified inheritance is one of them) and some questionable or errorphrone contructs left out. The "No global functions" is something you can live with since static methods are possible. Threading in particular is well supported in .NET/C#. You fail to specify the deficiencies that overweight the advantages. Here is my incomplete advantage list (using C# version 2.0):

- Feature rich framework that presents lots of stuff a programmer needs in a coherent and well documented form.

- Garbage collection frees your mind from memory handling.

- Safety. No buffer overruns, segmentation faults, etc.

- Reflection capabilities.

- Some handy syntax sugar (anonymous methods, iterators, properties, indexers).

- Type safe and more powerful callbacks (delegates)

- Enumerations introduce a new scope.

- Versioning via new/override. Every declared virtual method is the root of dispatch.

- Unified type system with a common base class, bridging the gab with boxing/unboxing.

- No distinction between pointers and references. No need for -> * &.

- Definite Assignment of variables. The crystal clear ref and out syntax.

- Checked arithmetic.

- Rectangular arrays.

- ...

I leave it here. There is certainly some point that I unintentionally left. Maybe you can come up with your disadvantage list ;-)


By Anonymous at Fri, 2004/05/14 - 5:00am

I do not want to post a list of advantages or disadvantages. Programmers clearly have different opinions whether a particular feature is good or bad. So just putting a list together will just perpetuate an unhelpful discussion.

I want however to pick on one feature of C# you mentioned. It is "Type safe and more powerful callbacks (delegates)". Why is that a new feature of C#? You just have to look at boost::signal and boost::function. Both of them provide delegating and similar capabilities. The core language of C++ is powerful enough to make a library implementation of this possible. This is a key difference, The support for programming generic components in C# is still not powerful enough (and won't be with C# v2.0 presumably) to achieve similar things in C#. It enables one not much more than to write generic containers and doing simple method dispatch.


By El Pseudonymo at Fri, 2004/05/14 - 5:00am

- Feature rich framework that presents lots of stuff a programmer needs in a coherent and well documented form.

* More libraries and frameworks for C++ than for C#

- Garbage collection frees your mind from memory handling.

* Handling memory allocations based on specific cases gives smaller/faster programs.

- Safety. No buffer overruns, segmentation faults, etc.

* The possibility to use pointers when needed

- Reflection capabilities.

* Templates, generic programming

- Some handy syntax sugar (anonymous methods, iterators, properties, indexers).

* A lot of compilers, direct compattibility with C and fast bindings for every existing language. Ability to add inline assembly for fully utilizing your CPU when nedded.

- Type safe and more powerful callbacks (delegates)

* Ability to evict type safety when needed

- Enumerations introduce a new scope.

* namespaces

- Versioning via new/override. Every declared virtual method is the root of dispatch.

* Dunno if this is a feature :)

- Unified type system with a common base class, bridging the gab with boxing/unboxing.

* You can have it too in C++, it's your decision

- No distinction between pointers and references. No need for -> * &.

* What's the feature here?

- Definite Assignment of variables. The crystal clear ref and out syntax.

* ?

- Checked arithmetic.

* ?

- Rectangular arrays.

* You can find a myriad of C/C++ libs for handling arrays

- ...

* Compiled language, without the burden of a VM and GC, _optional_ GC to come.

I just dont understand why people are so hyped for languages that use a VM. Portability does not work there too, see java. The vm makes them heavyweight and makes your new PC look like a 386.


By anon at Fri, 2004/05/14 - 5:00am

"More libraries and frameworks for C++ than for C#"

You point out the crux with C++. The standard library leaves a lot to be desired and so you have a lot of libraries trying to close the gap. Unfortunately most of them are redundant featurewise and deciding between the zillions of libraries essentially doing the same thing for a given purpose but differing in their API styles and concepts make life harder for programmers. Why do you think are so many people interested in Qt? Its because Qt offers a unified framework that offers a lot more than just GUI functionality and that is badly needed for C++. I however prefer one coherent and well thought framework I can rely on. You know less is more sometimes.

"Handling memory allocations based on specific cases gives smaller/faster programs."

This claim needs to be proved. Besides the usual laypersons believe GC does not have to yield slower and bigger programs.

"The possibility to use pointers when needed"

This possibility exists in C# as well.

"Templates, generic programming"

Those features certainly do not outweight the lack of reflection. Besides I referred to version 2 of C# which directly supports generics.

"A lot of compilers, direct compattibility with C and fast bindings for every existing language. Ability to add inline assembly for fully utilizing your CPU when nedded."

There are at least 3 .NET/C# implementations at this time and this is an implementation detail that has nothing to do with language capabilities. What you could mean with "bindings for every existing language" is beyond me--it is certainly not easy to access eg. Python from C++ (and Python is one of the easier ones). Invoking C/C++ functions is straightforward from C# via P/Invoke.

"Ability to evict type safety when needed"

First time someone tries to present this as a feature to me.

Concernign the unified type system. Your claim is I can have it in C++ too and this is definately wrong. C++ doesn't have a unified type system. There are basic types (eg. int, float) and user defined ones (via classes). This gap can't be closed in C++.

"I just dont understand why people are so hyped for languages that use a VM. Portability does not work there too, see java. The vm makes them heavyweight and makes your new PC look like a 386."

The hype is not about VMs. It is about coherent frameworks and simple languages that don't impose barock syntaxes and semantics caused by backward compatibility desires. Portability with VMs is possible and works fine with Java.


By Anonymous at Sat, 2004/05/15 - 5:00am

Is there any reason for me to develop anything in C#?. I am starting a project with C/C++, though time consuming, I am building a GUI, with a complex database, and a new file format. Is there anything I can save some time and build with C#? or is it as limited as it looks? translated code has never worked for me in the past. Should I try again?

thanks

Albert


By albert goldwyn at Wed, 2008/07/09 - 5:00am

I forgot to answer: "And how do you mean that GC is forced upon you in C#?"

Easily answered, you have unpredictable disposal of ressources in C#, if you do not do disposal yourself.


By El Pseudonymo at Fri, 2004/05/14 - 5:00am

If your class implements the IDisposable interface (basically requiring you to write a Dispose() method) you might want to use the 'using' contruct which calls Dispose() automatically even in the case of exceptions. So your resources are freed at the earliest possible time.


By Anonymous at Sat, 2004/05/15 - 5:00am

You are right. I never heard about that. So one main point of my critique is alleviated. But problems still remain, because in order to use "using" you have to declare a variable. This isn't possible everywhere and in many places it would make the code harder to read. And as far as I know, there is no way to "remove" "using" from a variable.


By El Pseudonymo at Sat, 2004/05/15 - 5:00am

> What is it that is so fantastic with C#?

Two years from now, how many developers do you think will be using C# and .NET? I think it will be a lot.

Having Qt C# bindings will lower the barriers for all these developers to participate in developing free software (or, more likely, make their proprietary software work on KGX).

It's not about what is the best technology, rather it's about the marketing reality of Microsoft that will push many developers to .NET, and lowering barriers for those developers and their apps work on KGX. Anyway, that's how I see it ...


By mbucc at Wed, 2004/05/12 - 5:00am

There will probably be a lot of C# developers two years from now that still just take it for granted that C# will save the world :)

I'm not against making Qt C# bindings. I think one should add support for C# in KDevelop, so that that all these new developers will be able to use a real IDE, not to mention run their CLRs at twice the speed in dotgnu.
I also think that this new language 'D', (announced on Slashdot two weeks ago) should be integrated into KDevelop as well as get Qt bindings.


By Vegard Figenschou at Wed, 2004/05/12 - 5:00am

I was also very impressed with "D" - it should be the successor to C++ but that doesn't mean it will be. I'm afraid that unless the C++ committee powers drop their egos and adopt it(unlikely) or some big software company adopt it into a major IDE effort, that D will just float around out there as another great technology with no real support. Most programmers know C, C++, Java, and maybe now C#. Students are learning C, C++, Java, and C#. It takes something really big to alter that entrenched skill base.


By John at Thu, 2004/05/13 - 5:00am

Snif, snif. I'm sad :-( because I don't know why there is so much attention to languages like C# or Java.

Try Smalltalk! It's there since the 80's and has a lot of features still not available in C# or Java. (here http://www.whysmalltalk.com/articles/panici/considered.htm is some ST propaganda ;-) )

I would like to see some open source Smalltalk implementation with support of native widgets like Qt or GTK (Squeak - http://www.squeak.org - it's nice... but doesn't have support to create "normal" desktop applications).

But, if I have to use Java... I would like see an implementation of SWT (http://www.eclipse.org) with Qt. The linux implementation of SWT is GTK only :-( ouch! I think that making Java applications look like native KDE applications would be great.

(sorry, my english is not good)


By Diego at Thu, 2004/05/13 - 5:00am

Smalltalk is not really a competitor to C# or Java, rather to Ruby and Python. It is not a statically type-safe language. It's in a different league (I leave to you whether it is better or worse for system programming).

Beside that, Smalltalk's syntax is weird in a world where people are used to C-style and Basic-like languages. That alone is enough reason to rule out a wide-spread adoption.


By AC at Thu, 2004/05/13 - 5:00am

I agree Smalltalk is still one of the best languages for developing GUIs, apart from the unusual syntax if you aren't used to it, and non-native look and feels. But there are issues with the Squeak license (Debian doesn't include it for that reason), and I think GNU Smalltalk would be a better basis for a Qt/KDE language binding.

"But, if I have to use Java... I would like see an implementation of SWT (http://www.eclipse.org) with Qt. The linux implementation of SWT is GTK only :-( ouch! I think that making Java applications look like native KDE applications would be great."

Why do you think SWT is some sort of improvement over QtJava or the Koala KDE java api? SWT still has clunky event listener subclassing like the hard to use Swing framework, rather than slots and signals. You have to dispose() of all resources with no help from the garbage collector, and it's pretty limited for creating new custom widgets.


By Richard Dale at Thu, 2004/05/13 - 5:00am

Actually IBM did the port, but it was never released due to licensing problems. This was touched on a bit in the interview with the Trolltech guys on the dot recently.

Basically for such a port to exist and be useful it would need to be possible to run applications written in SWT regardless of license -- however this would mean running proprietary apps using a GPL'ed Qt which is a no-go.


By Scott Wheeler at Thu, 2004/05/13 - 5:00am

Uhmm!!! Why we need a C# implementation of QT??? it's so much work!!! But i have to admit that having a .NET implementation of QT would be really good!!!, in that sense why not to do a modification of QT to compile it with C++.NET (yes i know we don't C++.NET for Linux, but we could !!!) less work than doing a C# implementation (i think!!), and now that C++.NET will be standarized (see http://www.ecma-international.org/news/ecma-TG5-PR.htm), would be really good to have a C++.NET compiler for Linux and a QT.NET implementation!!! and this would be better that the bindings that are aleady in progress (http://sourceforge.net/projects/qtcsharp), it would have less dependencies!!!


By Ivan Deras at Mon, 2004/05/17 - 5:00am

Regarding memory allocation optimisations, I wonder if they have plans to support something like memory pools. The idea behind pools is that allocating an object has an expensive cost in time. If you have many allocations of small object to make, you should better allocate big chunks of memory, keep them in a pool and let the objects use the memory of the pool.

This could certainly be used where one allocates many instances of small objects. It could be for example an option of QList, or for QListViewitem.


By Philippe Fremy at Wed, 2004/05/12 - 5:00am

I like these news:-)

How far will the optimizations in Qt influence KDE performance?
How big (if necessary) are the needed modifications to KDE?


By ac at Thu, 2004/05/13 - 5:00am