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

Marc Mutz marc.mutz at kdab.com
Tue Oct 7 11:16:29 CEST 2014


Hi Kuba,

Your criticisms are completely valid, and the conclusions you draw from them 
are, too. The problems Thiago lists make this a daunting task, but mostly not 
because of complexity, but of sheer volume of code that needs to be modified.

I believe it's worth it, but most of us here lack the time for such a change, 
so you're more than welcome to volunteer. I can at least help with review, and 
once the class is in and QDir*/QFile* are adapted to use it, I'd start using 
it in QtWidgets right away.

Many of the issues Thiago lists can be dodged. E.g. a file path class could 
lack streaming operators and instead force early users to use 
toEncoded()/toDecoded() explicitly.

On Monday 06 October 2014 19:30:29 Kuba Ober wrote:
> I’d think that the solution could be to use a dedicated class for file
> names,

Yes, with s/file/path/.

> perhaps with a base class for uninterpreted platform strings.

Value classes should not have base classes. And that class for uninterpreted 
platform strings may be an abstraction vehicle to streamline implementation of 
path name class, but not public API, unless you provide one or two more users 
of such API.

Thanks,
Marc

-- 
Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin

Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions



More information about the Development mailing list