c++ - Char and string types, what should I use? -


at work i'm using c# want learn c++ , chars/strings confusing. example, know tchar can either regular char or, if i'm using unicode, wchar_t. so, use tchar? find questions is tchar still relevant?.
ok, let's use else...? far i've used char , std::string , @ point have no idea if approach or not, i'm bit lost.

what should use if i'm writing program not translated antother language?
what should use if i'm writing program translated antother language?
what should use if i'm writing program used in countries use latin characters, not have english native language (hello ä, ö, ü, ß, æ, Ø, ï...)?
there anthing can safely ignore because it's outdated?

heavily opinionated based on experience answer

before begin, let me state i've been working on c++ software 5 years, millions of users globally - in doing i've learned hell-of-a-lot how things work in real world.

the first thing understand windows inherently uses it's (originally homegrown) utf-16 standard (aka, wide-char). , in doing makes life much, harder. (almost) every other operating system uses utf-8. , mean; os x, *nix, android, ios, pretty can throw c++ compiler at.

because of this, ever intend use code outside of windows? if don't, there's no reason not "windows way", std::wstring being best-friend here. can use .c_str() const wchar_t * (and implicitly converts lpcwstr). many of these windows types (such lpcwstr, , tchar, macros (aka #define) you can read more on here.

should bother utf-16 wide characters @ all?
it's very think "what if ignore languages don't use latin alphabet", trust me when say, don't. yes, use multibyte characters only, or implicitly call the a variants of api functions. however, while works (and well), if support language beyond latin-types, run problems. , if don't, users expect input in native language.

tl;dr

english only, cross platform?- in short, there nothing inherently wrong using ansi 8-bit strings on windows-programming - won't crash internet, , if writing that know going used english-speakers across platforms (software america?) recommend changing project multi-byte, , using std::string everything, don't expect open a single file international filename.
, keep in mind, if user-base in thousands go utf-8, if in tens of thousands, people going mildly angered not being able load kanjii-filenames.

international, windows only - if software going come close approaching internet-border-of-sweden (where needs load file-name written in goa'uld), use std::wstring, use utf-16, , happy in windows-only software. honest, state of most windows software today.

international, mac's cool? - project manager wants cross-platform software yesterday, needs run on mac , pc - because users it's being deployed 16% mac users (according marketing), , needs have ime support arabic , japanese.
tell project manager going write wrapper api-calls, take week longer, prevent cross-platform language nonsense, if doesn't agree - quit.

then that, use utf-8 under bonnet, , have api-calls windows / mac system handled using wrapper-class wrote yourself. yes take effort , maintenance, lets save lot of time in long run.

extra links

if need very complex unicode support, check out icu library, osx uses under hood!)
learn use boost - filesystem support alone makes cross-platform c++ development much, faster


Comments

Popular posts from this blog

java - Run spring boot application error: Cannot instantiate interface org.springframework.context.ApplicationListener -

reactjs - React router and this.props.children - how to pass state to this.props.children -

Excel VBA "Microsoft Windows Common Controls 6.0 (SP6)" Location Changes -