[Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems

[Tomasz Siekierda]

On 7 October 2014 11:16, Marc Mutz <marc.mutz at kdab.com> wrote:
>> Ugh, that begins to sound like Java. Let's have a wrapper for a
>> wrapper... please don't go that way.

> We have QSize and QPoint and they're used ubiquitously in Qt. But, by your
> rationale, everyone should be using two ints instead, so let's remove them!

> How's that anything to do with Java? C++ is made from the ground up for
> lightweight abstractions such as a size, a point and a file path. It's Java
> that isn't.

QSize, QPoint, QRect, etc. are useful, very convenient, intuitive and
a good thing to have. For file paths, I feel QString is really enough.
Changing it to something else because of a few corner cases seems like
an overkill to me. We already have a lot of classes that are connected
with paths and the file system (QFile, QFileInfo, QDir, QDirIterator,
and more), that is enough. In my view, at least.

My reference to Java comes from their love for large amount of
abstractions and interfaces, where even the simplest action requires
creation of several objects of various classes that can't talk
directly to one another. One of the beautiful things about Qt is that
you can do a lot in a very few lines of code. Current use of QString -
IMO - works just fine, but maybe I have misunderstood something here.