Подскажите, пожалуйста, кроссплатформенное решение проблемы русского ввода и русского вывода на c++?

В ASCII ты русский язык никак не выведешь. Проще всего будет взять Qt и не страдать.

как это всё заставить работать в кодировке ASCII?

В ASCII нет русских букв, там только коды от 0 до 127.

Строки из Qt или GLibmm

Окей, хорошо тогда можно обойтись без ASCII, если да то как?

Можно ли использовать Unicode или там тоже будет проблема с русскими буквами?

QString - UTF-16

std::string - набор произвольных байт.

Делаем выводы.

сохраняй файлы в cp866? (нет)

ASCII

никак, лол. Уже все признали что без уникода никуда, хватит страдать хернёй. Ты ещё бы koi-7 взял. Причём, обычно берут utf16 в памяти (спасибо корпорациям, блин), и utf8 везде.

если пользователь ввёл строку, то её можно было корректно вывести ему обратно

Для этого ничего не нужно делать вообще, со строкой можно работать как с байтами.

чтобы если в программе была проинициализирована строка, содержащая русские буквы, то чтобы и её можно было также корректно вывести

Тут много вариантов. man wstring, setlocale. Можно обойтись iconv. А чтобы было удобно лучше взять что-нибудь повыше уровнем типа icu или Qt.

Use QString, Luke!

https://docs.microsoft.com/en-us/windows/console/console-code-pages

или кодируй строку для CP866 в libiconv

Если подразумевается консольный ввод-вывод и нужна совместимость с Linux и Windows, то можно использовать boost-nowide.

Если подразумевается консольный ввод-вывод и нужна совместимость с Linux и Windows, то можно использовать boost-nowide.

А с помощью стандартных библиотек C++ нельзя это сделать?

если пользователь ввёл строку, то её можно было корректно вывести ему обратно

- использование narrow потоков ввода-вывода(если не трогать локали, или трогать со знанием дела - там по умолчанию ввод-вывод «как есть», без преобразований)

- использование wide потоков + user-preffered локаль

если в программе была проинициализирована строка, содержащая русские буквы, то чтобы и её можно было также корректно вывести

- char + narrow I/O: при этом кодировка исходника дожна соответствовать таковой в user-preffered локали(в линуксах более-менее просто - в большинстве мест UTF-8, работает так: литералы char/char[] компилятор пишет в объектник «как есть»)

- wchar_t + wide I/O: здесь надо перед компиляцией перегнать исходник в кодировку из user-preffered локали: что-то типа `iconv -f $SOURCE_IN_ENCODING < $SOURCE_IN > $SOURCE`, "-t" не нужно, и уже его компилять(про то, что надо в приложении локализовать потоки тоже забывать не стоит)

А вообще да, use qt/boost/icu/libiconv

Едва ли можно. Если не хочется подключать даже такую небольшую библиотеку (там есть вариант без boost), то можно убрать из неё то, что не нужно.

Вообще, наверно, самый правильный вариант вывода в консоль не ASCII текста в Windows — это использование WriteConsoleW. (остальные варианты описаны на RuSO) Соответственно, можно реализовать свой std::streambuf, в котором конвертировать строку из char в wchar и потом выводить с помощью WriteConsoleW. Далее, этот streambuf передаётся std::istream и полученный istream можно использовать, так же, как и std::cout. В Linux же UTF-8 просто выводится с помощью std::cout. Собственно, в boost-nowide как-то так и сделано.

как это всё заставить работать в кодировке ASCII?

ASCII уже давно протухла. Использовать 8 бит под национальный алфавит оказалось не очень удобно. Обратная совместимость с US-ASCII есть в UTF-8, ее и советую использовать.

кроссплатформенное решение проблемы русского ввода и русского вывода на c++?

std + utf-8. Вот мой маленький экземпл, который прояснит многие моменты: https://gist.github.com/RotiVP/41475739072a5ebddaa82b9c23664ea4

std + utf-8. Вот мой маленький экземпл, который прояснит многие моменты: https://gist.github.com/RotiVP/41475739072a5ebddaa82b9c23664ea4

Твой эксепл кидает исключение на 10 строке, если скомпилировать его при помощи Visual Studio 2015, а вот если компилить с помощью g++ под Ubuntu Server то никаких исключений нет и всё работает корректно, почему?

puct' vvodiat latinicoi !

наверно в венде локали устанавливаются не так, ну и к чёрту эту венду, правда?

И да, кстати, сейчас на самом деле в большинстве случаев можно (и нужно) просто наплевать на локали (шарикту и его восьмибитные друзья могут проследовать куда хотят), выкинуть mb* функции и работать везде исключительно с utf-8. В новом стандарте и тип специально для этого появился. А уж если что-то дополнительно понадобится, типа нормальзиции или трансформаций (upper/lower case) я бы взял icu.

Русский язык невозможно латинизировать. Но не потому, что технически невозможно, а потому что каждый первый анонимус чешет любой лапой как попало.

работать везде исключительно с utf-8. В новом стандарте и тип специально для этого появился.

char8_t уже приняли в стандарт?

Зачем? Это char.

В char уже гарантировано лежит UTF-8?

Не менее гарантировано чем ASCII.

Если нужен транслит, то я как раз сегодня страничку обновил:

http://программирование-по-русски.рф/яролит.яргт/

фальшивый

falqshivyyyi

Понедельник начался с тяжёлых наркотиков

UPD: это ещё не самый эпик — о нас:

Not Found

The requested URL /о-нас.яргт was not found on this server.
Apache/2.4.10 (Unix) Server at xn-----6kcajervcdvqarhfgengcekya4c.xn--p1ai Port 80

Кириллизация, которую мы заслужили.

подскажу. UTF8

Можно ли использовать Unicode

Зачем Юникод когда есть KOI8-R? В виндовом cmd.exe тогда можно просто выполнить «chcp 20866», и он переключит кодировку на KOI8-R.

Зачем Юникод когда есть KOI8-R?

Зачем жить в нормальном жилье, когда есть старый сарай?

В виндовом cmd.exe тогда можно просто выполнить «chcp 20866», и он переключит кодировку на KOI8-R

Не всем нужно усложнять себе жизнь ради такого неоправданного фанатизма

Это можно считать разве что машинно-читаемым транслитом, ибо человеку читать такое невозможно.

Славянские языки без диакритики не латинизируются!

наверно в венде локали устанавливаются не так, ну и к чёрту эту венду, правда?

Мне нужно кроссплатформенное решение, используя только стандартные библиотеки.

На самом деле, смотря сколько за это будут платить. Если выбор стоит между двуязычием и транслитом в отдельных местах, которых не так уж много, я выберу такой транслит.

Но ладно, не буду больше загружать эту тему офтопиком :)

Пожалуйста НЕТ! Во всем нормальном мире пишут и код и коменты на английском. Что б прогер из другой страны мог понять о чем речь. Кроме того, что ты физически уменьшаешь количество потенциальных разработчиков способных поддерживать твой код, твое решение еще и просто уродливо. Я даже не знаю что выглядит хуже
Это?

falqshivyyyi ehkzemplyar

Или это?

jHjejljljo

Пол беды если б это решение было некрасивым, но действительно облегчало где-то жизнь. Но ты только делаешь хуже, внося несовместимость там, где она была. Это будут использовать только маргиналы вроде Эдди или могут попробовать ввести в проект какие-нибудь поехавшие менеджеры, которые сами не шарят в разработке.

Если хочешь всерьёз поговорить, то, пожалуйста, уклоняйся от использования определения «весь нормальный мир».

ASCII

KOI-7

уклоняйся от использования определения «весь нормальный мир»

Не буду уклоняться. Не в контексте этого изобретерия.

Тогда разговаривай с кем-нибудь другим.

Хрюникодофилы не поймут. Потреблядям невозможно объяснить, что они - потребляди!

Во всём нормальном мире пишут и код и коменты на китайском. В принципе всё равно, меня как носителя языка не слишком напрягают нормальные комментарии на русском (они куда лучше плохих на английском). Кому надо воспользуются гуглопереводчиком.

Меня тоже не особо напрягают коменты на русском(так как я сам русский и легко их читаю), если, конечно, исходники в юникоде. Так как иначе еще и начинается проблема с кодировками. Но надо понимать, что если твой код документирован на русском, то никто кроме русских его использовать не сможет. Если это закрытый софт и масштабирование команды не планируется - все ок. Если ты делаешь опен сорс или не знаешь, кто будет поддерживать твой код - документировать на русском не правильно.
Однако же писать коменты или код транслитом это всегда ужасно.

русский язык
Не подскажите

Моя твоя не понимай!

Комменты не на английском пишут только начинающие быдлокодеры и те, кому насрать на окружающих. Если хочется, чтобы увидев твой код люди не начали тебя материть на чем свет стоит, а сказали спасибо, воспользовавшись кусками твоего кода, комментарии надо делать на английском.

И вообще, в исходных кодах не должно быть символов, выходящих за пределы таблицы ASCII.

Возьми Qt с его QString и не парься, это лучшее что есть на сегодняшний день.

Хотя даже в них будут проблемы на различных операционках, особенно в поделии Билли:

Русские буквы в консольных приложениях Qt под Windows

Как в Qt работать с русскими именами файлов и директорий под Windows

Как в Qt узнать системную кодировку локали под Windows

Посты не на английском пишут только недалёкие и те, кому насрать на окружающих. Если хочется, >чтобы увидев твой пост люди не начали тебя материть на чем свет стоит, а сказали спасибо, >воспользовавшись информацией из него, посты надо делать на английском.
И вообще, в постах не должно быть символов, выходящих за пределы таблицы ASCII.

Надеюсь, это упырит мел пуристов(и, кстати, начинающих быдлокодеров тоже, лол:-)

кроссплатформенное

C++

не бывает такого
пиши костыль на каждую ОС

подскажу. UTF8

двухбайтовый чар с C++
сложно сказать что может быть хуже

Тот самый случай, когда пожар не потушить...

Не подскажите

Так и быть, не подскажем.

Так и быть, не подскажем.

Теперь подсказывай, я изменил название темы.