_O_WTEXT, _O_U16TEXT, _O_U8TEXT - возможны ли эти режимы в компиляторе mingw, есть ли обходные пути? - PullRequest
4 голосов
/ 15 января 2012
#include <fcntl.h>
#include <io.h>
#include <stdio.h>

int main(void) {
  _setmode(_fileno(stdout), _O_U16TEXT);
  wprintf(L"\x043a\x043e\x0448\x043a\x0430 \x65e5\x672c\x56fd\n");
  return 0;
}

возвращает ошибку при компиляции: _O_U16TEXT was not declared in this scope

Это остановка шоу с этим компилятором?

Ответы [ 2 ]

3 голосов
/ 05 марта 2016

Ну, есть простой обходной путь: просто используйте значения этих констант вместо их имен. Например, _O_U16TEXT равно 0x00020000, а _O_U8TEXT равно 0x00040000.

Я только что подтвердил, что он работает с _setmode, используя g ++ 4.8.1 в Windows 10:

#include <iostream>
#include <fcntl.h>
#include <io.h>
#include <stdio.h>

int main() {
    _setmode(_fileno(stdout), 0x00020000); // _O_U16TEXT
    std::wcout << L"Русский текст\n";
}
1 голос
/ 10 августа 2012

Даже не беспокойтесь об этом.

Ваш пользователь должен установить шрифт своей консоли в Unicode (например, Lucida Console), иначе он ничего не отобразит. Если вы ориентируетесь на Восточную Азию, где по умолчанию используется шрифт с поддержкой Юникода, он будет отображаться нормально, но в Европе вам придется изменить шрифт вручную.

Пользователь не изменит свой консольный шрифт, потому что вы пишете его в файле readme Они даже не будут читать файл readme, они просто увидят, что он отображает мусор, и подумают, что программа не работает.

Кроме того, это значительно новая функция VS 2005, поэтому вам нужно связать распространяемый VS 2005, msvcr50.dll или более новый (по умолчанию mingw ссылается на msvcrt.dll). Если вы этого не сделаете, текст вообще не будет отображаться.

И я думаю, что простой канал убьет ваш новый и блестящий текст в юникоде. Допустим, ваш exe с именем a.exe. Я почти уверен, что a.exe | more НЕ будет отображать текст Unicode.

...