I’m linking a text file into my project by adding it to the resource and then loading it.
I use LockResource and a static_cast to cast it to a std::wstring
std::wstring sData(static_cast<wchar_t*>(pData));
My project uses UNICODE (windows), which is why I’m using std::wstring and wchar_t.
I found out that I have to set the encoding in the file to UCS-2 LE, otherwise it would just read gibberish.
I’m guessing this is because that is what encoding Windows uses.
My question is, is it safe to assume all Windows operating systems currently use UCS-2 LE? I don’t want to run into a system using UCS-2 BE (or something else). My program would crash horribly.
I could save the file in ANSI, and then convert it to what ever encoding the operating system is using with MultiByteToWideChar, but this would be a waste of time if it’s definitely going to be UCS-2 LE.
All recent and current versions of Windows (excluding XBox) use UTF-16 LE.
Note that there’s a bug with how you’re initializing the string variable:
This assumes that the resource ends with a terminating (two-byte) 0, which I don’t think is guaranteed if you’re just referencing the file in your resources. You should get the size of the resource, and use the two-pointer constructor for sData.
If you’re worried about time (as suggested by your comment on using
MultiByteToWideChar), you should be aware that you’re copying the data from the resource into dynamic memory, and this copy is probably almost as slow as doing a conversion. If you’re doing this just once, I wouldn’t worry about the speed. I’d save the text as UTF-8, and useMultiByteToWideChar, especially if the UTF-8 encoding is more efficient for your text, as that would make your binary smaller.If speed is an issue (and if you don’t need to modify the string at run time), then I wouldn’t use a
std::wstringat all. I’d make a class that provides a similar interface, but have it point directly to the resource memory rather than copy the entire text into dynamic memory. That saves load time and memory.