wchar-t

Does wide character input/output in C always read from / write to the correct (system default) encoding?

独自空忆成欢 提交于 2019-11-30 13:51:00
I'm primarily interested in the Unix-like systems (e.g., portable POSIX) as it seems like Windows does strange things for wide characters. Do the read and write wide character functions (like getwchar() and putwchar() ) always "do the right thing", for example read from utf-8 and write to utf-8 when that is the set locale, or do I have to manually call wcrtomb() and print the string using e.g. fputs() ? On my system (openSUSE 12.3) where $LANG is set to en_GB.UTF-8 they do seem to do the right thing (inspecting the output I see what looks like UTF-8 even though strings were stored using wchar

Cross-platform strings (and Unicode) in C++

守給你的承諾、 提交于 2019-11-30 12:11:55
问题 So I've finally gotten back to my main task - porting a rather large C++ project from Windows to the Mac. Straight away I've been hit by the problem where wchar_t is 16-bits on Windows but 32-bits on the Mac. This is a problem because all of the strings are represented by wchar_t and there will be string data going back and forth between Windows and Mac machines (in both on-disk data and network data forms). Because of the way in which it works it wouldn't be totally straightforward to

char vs wchar_t

徘徊边缘 提交于 2019-11-30 09:28:16
I'm trying to print out a wchar_t* string. Code goes below: #include <stdio.h> #include <string.h> #include <wchar.h> char *ascii_ = "中日友好"; //line-1 wchar_t *wchar_ = L"中日友好"; //line-2 int main() { printf("ascii_: %s\n", ascii_); //line-3 wprintf(L"wchar_: %s\n", wchar_); //line-4 return 0; } //Output ascii_: 中日友好 Question: Apparently I should not assign CJK characters to char* pointer in line-1, but I just did it, and the output of line-3 is correct, So why? How could printf() in line-3 give me the non-ascii characters? Does it know the encoding somehow? I assume the code in line-2 and line

Cast (const) char * to LPCWSTR [duplicate]

守給你的承諾、 提交于 2019-11-30 09:24:26
问题 This question already has answers here : How do I convert a char string to a wchar_t string? (4 answers) Closed 5 years ago . I'm trying to use FindWindow() from WinAPI, and I want to ask an input for window's title from the user: char *input; cout << "Window title: "; cin >> input; Pretty standard. Now then, how do I convert this to LPCWSTR for FindWindow() ? I've already tried the following: _T(input) , TEXT(input) , (LPCWSTR)input but none of them worked. I also tried using wchar_t instead

Cross-platform strings (and Unicode) in C++

孤街醉人 提交于 2019-11-30 02:08:36
So I've finally gotten back to my main task - porting a rather large C++ project from Windows to the Mac. Straight away I've been hit by the problem where wchar_t is 16-bits on Windows but 32-bits on the Mac. This is a problem because all of the strings are represented by wchar_t and there will be string data going back and forth between Windows and Mac machines (in both on-disk data and network data forms). Because of the way in which it works it wouldn't be totally straightforward to convert the strings into some common format before sending and receiving the data. We've also really started

char vs wchar_t

不想你离开。 提交于 2019-11-29 14:24:52
问题 I'm trying to print out a wchar_t* string. Code goes below: #include <stdio.h> #include <string.h> #include <wchar.h> char *ascii_ = "中日友好"; //line-1 wchar_t *wchar_ = L"中日友好"; //line-2 int main() { printf("ascii_: %s\n", ascii_); //line-3 wprintf(L"wchar_: %s\n", wchar_); //line-4 return 0; } //Output ascii_: 中日友好 Question: Apparently I should not assign CJK characters to char* pointer in line-1, but I just did it, and the output of line-3 is correct, So why? How could printf() in line-3

Outputting unicode characters in windows terminal

£可爱£侵袭症+ 提交于 2019-11-29 10:49:46
Over the past week I've been working on a roguelike game in C++ along with a friend. Mostly too learn the language. I'm using: pdcurses Windows 7 Visual studio C++ To output wchar_t 's wherever I want to in the console. I have succeeded in otuputting some unicode characters such as \u263B (☻), but others such as \u2638 (☸) will just end up as question marks(?). Here's the relevant code I use for output. // Container of room information struct RoomInfo { wchar_t * layout; int width; int height; }; // The following function builds RoomInfo RoomInfo Room::examine(IActor * examinor) { RoomInfo ri;

How do i convert const wchar_t* to System::String?

北城余情 提交于 2019-11-29 07:50:34
I need to convert my SHA1 (wchar_t*) to a normal String^ in order to use it in a certain function. Any ideas? I tried Google but all the results were the exact opposite of my question. :\ NOTE: I am using C++.NET framework and Windows Forms Applications Use the constructor; like this: const wchar_t* const pStr1 = ...; System::String^ const str1 = gcnew System::String(pStr1); const char* const pStr2 = ...; System::String^ const str2 = gcnew System::String(pStr2); If you're using the standard C++ string classes ( std::wstring or std::string ), you can get a pointer with the c_str() method. Your

Is endian conversion required for wchar_t data?

老子叫甜甜 提交于 2019-11-29 07:04:33
In C/C++, if a multi-byte wide character (wchar_t) value is transmitted from a big-endian system to a little-endian system (or vice-versa), will it come out the same value on the other side? Or will the bytes need to be swapped? Yes you will need to swap them. The bytes will be retrieved from the transport in the same order they were put in. Just at the other end the ordering of these bytes has a different meaning. So you need to convert them to the correct endian-ness (is that a word?). The tried and true method is to convert to network byte order before transport. Then convert back to host

Why isn't wchar_t widely used in code for Linux / related platforms?

隐身守侯 提交于 2019-11-29 07:02:04
问题 This intrigues me, so I'm going to ask - for what reason is wchar_t not used so widely on Linux/Linux-like systems as it is on Windows? Specifically, the Windows API uses wchar_t internally whereas I believe Linux does not and this is reflected in a number of open source packages using char types. My understanding is that given a character c which requires multiple bytes to represent it, then in a char[] form c is split over several parts of char* whereas it forms a single unit in wchar_t[] .