Hacker News new | ask | show | jobs
by rileymat2 1638 days ago
A lot of the article is about string handling, I very much agree with that part of the article, having worked on a lot of legacy code built over decades before the introduction of UTF-8 compatibility.

It gets worse with that old code if you try to share modules between windows and Linux applications.

Additional complications come from trying to support TCHAR to allow either type of char for libraries.

Anyway, I have ended up supporting monstrosities of wstring, string, CString, char *, TCHAR mushed together, constantly marshalled converted back and forth.

And more: https://docs.microsoft.com/en-us/cpp/text/how-to-convert-bet...
1 comments
CountSessine 1638 days ago
Agreed! And TCHAR was the dumbest of all of them. “Not all of our libs/tools/editors support Unicode yet so use TCHAR in the meantime and then one day when our stack supports it fully then you can throw the switch and all your char*’s will be wchar_t*’s and I’m sure that’ll go really well in your codebase.”
link
cesarb 1638 days ago
> And TCHAR was the dumbest of all of them. “Not all of our libs/tools/editors support Unicode yet so use TCHAR

The reason for TCHAR is not "libs/tools/editors" not supporting Unicode, but the operating system itself. With TCHAR and related types, the same source code could target both Windows 95 and Windows NT, you just have to change a single #define (ok, IIRC there are actually three #defines: UNICODE, _UNICODE, and another one I can't recall at the moment) and recompile.

link