On 2016/03/23 02:51 PM, Fat-Zer wrote:
2016-03-23 5:31 GMT+03:00 Michele Calgaro michele.calgaro@yahoo.it:
On 03/23/2016 09:39 AM, Fat-Zer wrote:
I disagree with Alex on point 2). I would still go for TQString::fromUtf8() if I am handling strings from the OS, just in case ;-)
Just a thought experiment: Imaging a spherical user in a vacume, on an island free of friction far far away. For simplicity let's say his system has some single imaginary locale (LC_ALL=xx_XX.NON_UTF). A user types in the terminal: "touch 'ટેસ્ટ' ". And it creates a file "ટેસ્ટ" with name encoded in NON_UTF. Exactly the same record will be on the filesystem since nor touch, nor the linux kernel, nor extX driver don't do any encoding conversions. Then he desires to open that file with a tqt program. Somewhere deep inside TQDir it gets a string from readdir() that contains exactly "ટેસ્ટ" encoded in the same NON_UTF encoding... What should be next? TQString::fromUtf8(), which makes so simple string "ટેસ્ટ" look like some gibberish and causing the angry user to loose his belief in humanity and become a serial killer? Or use TQString::fromLocal8Bit() so he could be happy and see the "ટેસ્ટ" in his TQOpenFileDialog.
Luckily, now systems with non-utf8 locales are mostly extinct at least on linux and desktops...
Uhm, makes sense, good point. Interestingly my disagreement with you came from the other way around: what if the filesystem is using a 16bit or 32bit encoding? How would TQString::fromLocal8Bit() interpret that? Anyhow it was just my 2 cents :-) Cheers Michele