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

[Kuba Ober]

On Oct 7, 2014, at 8:30 AM, Julien Blanc <julien.blanc at nmc-company.com> wrote:

> On 07/10/2014 12:11, Tomasz Siekierda wrote:
>> 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.
> 
> Imho using QString for file path (or, more generally, using any string 
> objects with a static api) is somewhat a very widespread bad idea. The 
> std::experimental::filesystem  api, for example, looks really better.

Basically, on Unix, the idea that a file path has any particular encoding
doesn’t hold *by the very design*. On Unix, a file path is a string of nonzero
bytes with a special meaning for ‘/‘ and ‘.’ and that’s it. It’s a safe
assumption that other bytes under 128 are ASCII, perhaps, but even that’s not
an assumption one has to make.

Armin describes it rather succinctly:
"it's a byte mess that for display purposes is decoded with an encoding hint."

Given that Qt’s lifecycle is very different from that of standard C++, whatever
solution Qt provides needs to stand on its own.

Cheers, Kuba