Open bobbymcr opened 7 years ago
Does this have value before the project is localized to a language that wants more than ANSI?
What's the easiest way to do this and have it work on all platforms/compilers?
I suppose it has value if you expect non-Latin characters in messages and file names (which can and does happen even on 100% en-US systems). Perhaps it's even more likely for locale-aware projects under test (I'm thinking of a case where the expected and actual string values are being printed in an assertion failure message).
Assuming that C++11 is a prereq here, http://en.cppreference.com/w/cpp/locale/codecvt should make this relatively straightforward and portable.
On Tue, Feb 21, 2017 at 8:13 AM, Jay Bazuzi notifications@github.com wrote:
Does this have value before the project is localized to a language that wants more than ANSI?
What's the easiest way to do this and have it work on all platforms/compilers?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/JayBazuzi/Okra/issues/6#issuecomment-281391407, or mute the thread https://github.com/notifications/unsubscribe-auth/AE_9WcUx9enchYxsAzaWLqmkoNry8ebeks5rew0wgaJpZM4MHd2n .
Yes, I definitely want people to be able to write anything they like in to the names, so fixing this makes sense.
I am disappointed that they'll be constrained to the file system name limitations, and that those rules vary by platform. They already contend with that today, and it's less constraining than identifier names, as used by many test frameworks.
I wrote a test for this, but I don't know enough to fix it. Maybe someone can help?
The project includes tchar but uses only "narrow" (ANSI) strings. Maybe explicit Unicode would be the best choice? In that case you could consider ditching the W-vs-A tchar header and use only wcout, wmain, etc. Or maybe go with utf-8, though I don't know how much complication that would add.