Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
QStringLiteral Explained (woboq.com)
17 points by Tsiolkovsky on May 21, 2012 | hide | past | favorite | 9 comments


This seems like the perfect case where the compiler should just do the right thing, instead of having the programmer remember tons of rules.

And aren't, like, 99% of Qt programs UIs? Since when have UIs been so sensitive to performance that they have to be written in C++?

And x 2, they're using reference counting, which is about the worst form of garbage collection, and then worrying about the time taken to copy a string!


Sure, most Qt programs are UI based, which makes performance a sensitive issue. Even if you're running your UI on separate threads there's still a need for low-level aspects like strings to be as fast as possible. QString is used everywhere, the faster it is the smoother your application.


For a program that will sit waiting for user interaction nearly 100% of the time, strings must be "as fast as possible"? That's leaving aside the small fact that they won't be as fast as possible because you're using ref-counting.

My bigger point is that programming hasn't grown up yet. We're not an engineering discipline, using the best tools and making the highest quality things. We're stuck in this ridiculous world of shaving nanoseconds from string copies, at the cost of programmer time (which is vastly more expensive) and user dissatisfaction (when the programs crash).


Well, with QML... http://en.wikipedia.org/wiki/QML

Although, we've run into issues where the garbage collection in QML suddenly kicks in and causes skipped frames leading to jerky animations. Garbage collection is not a panacea, especially not if you want predictable performance, which a responsive and smoothly animating UI requires. There might be solutions like doing incremental time-bounded garbage collection or by not allowing garbage collection at all on the critical, has to run at screen refresh, animation path.


I seriously hope that Qt guys aren't relying that an unicode character (whatever that means) fits in 16 bits.


It says they use UTF-16 (just like Windows, Java and .NET), which represents code points outside the basic multilingual plane using a pair of 16-bit values and is thus capable of encoding the whole range of code points. The blog post author happens to confuse the terminology, but UTF-16 is sound.


I spend quite a lot of time working with Qt so it's nice to have the curtains pulled back, and new components explained in some depth. You occasionally miss the comprehension when it's just listed as 'This release has <x> feature'.


Unfortunately there are a lot of spelling errors making it difficult to read.


The author is from Germany and quite frankly that level of English is better than my level of German and a few language oddities don't take away from an interesting post.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: