Parker Coates parker.coates at kdemail.net
Wed Oct 6 00:21:53 BST 2010

On Tue, Oct 5, 2010 at 18:09, Thiago Macieira wrote:
> On Tuesday 5. October 2010 22.20.33 Parker Coates wrote:
>> It certainly takes away from the "Wow! QStrings are really easy to
>> use!" experience often encountered when working with Qt for the first
>> time and replaces it with "Oh, Qt has different string types for
>> different types of text and I have to pay attention to which I use
>> where."
> You *have* to pay attention to the encoding anyway, regardless of whether you
> have the cast macros or not. The macros simply help you understand where you
> must pay attention, instead of silent conversion.

I'm not actually convinced that one has to pay attention in many
cases. At least I wrote my first few Qt applications just fine without
thinking about encodings with the exception of one simple rule: string
literals should be ASCII only. [1]

This was mostly because the Qt APIs do a wonderful job of letting you
treat text as text and characters as characters. It's only if/when you
want to convert text to bytes or vice versa that the encoding issue
comes up. Of course then, I agree, it's very important to pay
attention and banning implicit conversions makes a lot of sense. A
"char *" is a very dangerous thing. :)

My opposition to enabling this macros centres solely around literals.
If there were a syntax for QString literals or a way for the compiler
to distinguish between literals and arbitrary char pointers (enabling
automatic converion in the former, but not in the latter) then I would
fully support this proposal. But I just don't think wrapping every
single literal with a constructor or conversion function is improving
code quality. [2]

But I'm certainly no expert in this area, and if the most
_application_ developer feel that this is a move in the right
direction, then I guess I'll just have to get used to it.


[1] Is it possible to make the compiler (or, if not, Krazy) warn when
using characters > 127 in literals?

[2] http://websvn.kde.org/trunk/KDE/kdegames/kpat/mainwindow.cpp?r1=1179446&r2=1179445&pathrev=1179446

More information about the kde-core-devel mailing list