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
Post a Comment