[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