как вводить русские буквы?

Начать можно отсюда. Много боли тебе предстоит узнать и в говно окунуться по уши.

ЗЫ

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

Вот так оно и работает. Тут конечно просто не будет стандартными средствами. Наверное самое простое решение - используй Qt.

Под офотопиком твой код прекрасно отрабатывает без всяких измененией. Компялятор BCC32C

1) В какой кодировке у тебя сохранён текст программы?

2) В какой среде ты её запускаешь?

3) setlocale(LC_ALL, «rus»); - такой локали не существует, насколько мне известно

Прикольно, сразу два пятизвёздочника расписались в том что они не знают С++ и консольный ввод/вывод.

текст программы сохранен в файле .cpp запускаю в vs19 setlocale(LC_ALL, «rus»); ну у меня всегда работало

используюмую локаль надо еще указать cout документация и пример

может это что-то не то? у меня в сами переменные записывает кракозябры

Тебе русские буквы нужно или UTF-8?

Если просто русские, то смени "rus" на ".866"

Если Unicode, то используй wchar_t.

https://imgur.com/a/u7L6PED

Вот пример с wchar_t: https://docs.microsoft.com/ru-ru/cpp/c-runtime-library/reference/setmode?view=msvc-160#example-use-_setmode-to-change-stdout

Я написал, что стандартными средствами не просто с этим работать. И что проще будет с Qt. В чем я не прав?

В чем я не прав?

В том что чтение документации на https://docs.microsoft.com сложнее, чем чтение документации на https://doc.qt.io

Я думаю, что неважно что читать. Это одинаково легко.

А так можно продолжать и написать, что вот тут вообще лёгкая документация: https://docs.oracle.com/en/java/

или тут https://docs.python.org/3/

vs19 setlocale(LC_ALL, «rus»)

На винфак.

Ну вообще документация Qt лучше составлена чем от микров. Но ладно микрософт. А вот что с gcc делать? Там тоже по твоему сопоставима с Qt-шной?

Кроме того codecvt_utf8 вообще deprecated с C++17 и в будущем может опять что-то новое запилят. Поэтому с точки зрения трудоемкости, пока проще юзать сторонние либы.

Я думаю, что неважно что читать. Это одинаково легко.

Ага, конечно. Ты еще скажи, что текст стандарта также легко читается, как документация Qt или книга Мейерса.

Ну вообще я ради фана скопипастил этот код в исходник с кодировкой UTF8, и он у меня отказался компилироваться. Ибо у русских букв коды выходят за пределы char.

Перекодирую исходник в 1251. Заменяю твой setlocale на

setlocale(LC_ALL, "ru_RU_cp1251");

и вах — всё прекрасно работает. Linux 64-разрядный.

Но вообще в реальных больших проектах действительно НЕ рекомендуется тащить нелатинские буквы в исходники и пользоваться файлами перевода. Таже если это c++, а не c — лучше вообще отказаться от char[] и пользоваться строками с поддержкой юникода. Например, QString из Qt, да.

Вот пример с wchar_t: https://docs.microsoft.com/ru-ru/cpp/c-runtime-library/reference/setmode?view=msvc-160#example-use-_setmode-to-change-stdout

Ты серьёзно на ресурсе о линуксе рекомендуешь человеку документацию, из-за которой его программа может оказаться прибитой гвоздями к Windows? Конкретно в этом примере _setmode() вылезает…

Юникод призван решить эту проблему, но в кресты и си его не завезли, только через сторонние монстроподобные библиотеки

Не так. Есть ещё wchar_t, который прямо в glibc'е.

прямо в glibc'е.

Ты серьёзно рекомендуешь человеку документацию, из-за которой его программа может оказаться прибитой гвоздями к POSIX?

А так прибита к Qt. Что гораздо хуже. Никто не мешает сделать заглушку _setmode для не Windows.

А советовать 1 гигабайтную зависимость для вывода текста в консоль, это совет от бога.

Если Unicode, то используй wchar_t.

🤦

🤦🤦🤦🤦🤦🤦🤦🤦

Читать про то что стандарт говорит про размер wchar_t и какого размера есть символы в юникоде до просветления

Что не так?

wchar_t - type for wide character representation (see wide strings). Required to be large enough to represent any supported character code point (32 bits on systems that support Unicode. A notable exception is Windows, where wchar_t is 16 bits and holds UTF-16 code units) It has the same size, signedness, and alignment as one of the integer types, but is a distinct type. 

Зачем ты что-то пишешь в темах про С++, если ты ничего об этом языке не знаешь?

https://en.cppreference.com/w/cpp/language/types

🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦

А это уже другой вопрос. В GNU решили, что 4 байта на юникодный символ хватит всем. Если Вы с этим не согласны, то пишите им в багзиллу: https://www.gnu.org/software/libc/bugs.html .

Юникод призван решить эту проблему, но в кресты и си его не завезли

В 2020 году не иметь поддержки Unicode такое себе. Идут ли разговоры для добавления его поддержки?

32 bits on systems that support Unicode. A notable exception is Windows, where wchar_t is 16 bits and holds UTF-16 code units

Тебе на русский перевести или сам сможешь?.

vs19

это друг мой винда, не линупс

А вот тебе для ознакомления, например для самого популярного UTF-8. 4 байта, это у нас 32 бита, не лезет.

ЗЫ

Вообще откуда столько «разработчиков», которые книжку по плюсам осилили, а матчасть предметной области и читать не осилили.

4 байта да, хватит. А вот в microsoft и vs (о которой в треде и речь), так не думают.

Qt

1 гигабайтную зависимость

Ути-пути.

У моего проекта в статической сборке с QtCore, QtGui, QtXml и кажется, даже QtNetWork бинарник под винду занимает 11 МЕГАбайт. Всё собираюсь и под линукс статический бинарь сделать (пока реп хватает), но сомневаюсь, что разница в разы, тем более на порядки.

На машине разработчика оно, конечно, больше занимает.

Никто не мешает сделать заглушку _setmode для не Windows.

Не мешает. Тому, кто знает, что это непереносимая функция. А ты посоветуешь новичку съесть непереносимую каку, он благополучно её под виндой соберёт и запустит. А проблем огребёт гораздо позднее.

для вывода текста в консоль

Это ж учебный пример.

А это проблемы Мелкософта. Не всем нужна кроссплатформенность. Главное, что всё работает в GNU/Linux'е.

ru_RU.cp1251

нормальные посоны используют

std::setlocale(LC_ALL, "ru_RU.UTF-8");

и wchar_t, а вообще QtCore.

char32_t тогда уж

https://en.cppreference.com/w/cpp/language/types

QtCore имеет лицензионные ограничения. Либо ты пишешь опенсорс, либо покупаешь лицензию и она очень дорогая, не для индивидуального разработчика.

в России кто-то что-то приобретает? Все вокруг пользуются Qt в закрытом виде для прибыли или работы предприятий.

Зависит от того на кого работают и с кем.

бинарник под винду занимает 11 МЕГАбайт.

Жирно, надо как разработчики КолибриОС впихивать графические приложения в БАЙТЫ!

Разработчики КолибриОС — мегаперцы.
Но уменьшать размер ценой прибивания своих программ к интеловской архитектуре я не готов.

Либо ты пишешь опенсорс, либо покупаешь лицензию и она очень дорогая, не для индивидуального разработчика.

man LGPL

setlocale(LC_ALL, "ru_RU.KOI8-R");

же.

Нынче много компонентов Qt уже под GPL, а не LGPL

Правильно ли понимаю, что если я бесплатно использую Qt либы и линкуюсь с ними только динамически, то мой софт при этом может быть закрытым?

Судя по фильтрам Core еще доступно под LGPL3, значит ее можно динамически слинковать, а свои исходники закрыть и продавать прогу в таком виде, так с дивана вижу, опыта продажи не имел.

Только для части компонентов Qt. Их продали более жадной компании, которая во всём что они сделали после предшественника поменяли LGPL на GPL. Выше человек правильную ссылку дал.

Судя по этим фильтрам, чуть менее чем весь Qt как фреймворк под LGPL, с исключениями в виде отдельных некритичных аддонов.

Нынче много компонентов Qt уже под GPL, а не LGPL

Основные модули Qt (Qt Essentials) под LGPL/GPL. QtCore в первую очередь.

Правильно ли понимаю, что если я бесплатно использую Qt либы и линкуюсь с ними только динамически, то мой софт при этом может быть закрытым?

LGPL налагает следующие требования:

1. если ты патчишь саму Qt (что бывает крайне редко), патченый исходник тоже должен быть под LGPL либо GPL;

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

С первым требованием всё понятно, а второе можно выполнить разными способами:

1. таки да, линковать динамически;
2. предоставить получателю объектные модули своей программы;
3. предоставить получателю исходный код своей программы (что не делает твою программу опенсорсом, например, в заказной разработке предоставлять исходники часто требует договор, но это не опенсорс);
4. выпускать исходники своего продукта под свободной лицензией.

Конечно, для большинства писателей проприетарного ПО самый простой способ — первый. И более того, для более-менее больших программных комплексов он оправдан, по сути дела единственный случай, когда статическая компоновка оправдана — это если всё ПО состоит из одного монолитного бинаря. Поэтому данное требование LGPL часто упрощают, в частности, можно встретить утверждение «LGPL запрещает статическую линковку». В такой формулировке это — эталонно-дебильная чушь (помимо прочего, LGPL никакую линковку и прочее использование на твоей машине запретить не может, ограничения касаются только распространения итогового продукта), хоть и основанная на реальных фактах.

Вывод: да, непатченные модули из перечня Qt Essentials при динамической компоновке со своими программами ты можешь законно распространять под проприетарной лицензией (но это не единственный вариант).

Их продали более жадной компании

Но я таки на всякий случай напоминаю, что «нежадная компания» — это Nokia, у которой деньги делались совсем на другом (да, за оLGPLенный Qt ей огромное спасибо). А «жадная компания» — это Digia -> Qt Group, которые, собственно, и занимаются разработкой Qt и которые других источников дохода не имеют.

Поэтому в их желании стрясти побольше денежек с проприетарщиков нет ничего плохого. Другое дело, что это можно было бы делать более гибко (например, ввести более доступные лицензии и/или убрать дурацкое ограничение на «смешивание версий»). Они хорошие разработчики, но маркетологи из них, похоже, не очень (на ЛОРе кто-то кидал ссылку на плач человека из Qt Project, что деньги на Qt умудряются заработать все кто угодно, кроме самих Qt Group).

запускаю в vs19

Ну и чего ты тогда забыл на сайте, посвящённом GNU/Linux и СПО?

std::u16/u32string + std::wstring_convert + std::codecvt

И не надо впихивать Qt и хардкодить локали.

std::string utf16_to_utf8(std::u16string utf16_string)
{
    std::wstring_convert<std::codecvt_utf8_utf16<int16_t>, int16_t> convert;
    auto p = reinterpret_cast<const int16_t *>(utf16_string.data());
    return convert.to_bytes(p, p + utf16_string.size());
}

никаких арифметики указателей тут не нужно, from_bytes/to_bytes спокойно жрут константные строки

да, сам почти всегда конвертирую в u16string

Хранить исходники в UTF-8 и не страдать. В Unix-подобных системах всё из коробки работает, а в Windows есть chcp 65001. Не слушайте других про Windows-1251, KOI-8 и прочие архаизмы.

И не надо впихивать Qt

И куча плохо читаемой лапши для действия, которая в Qt5 делалось одной строкой с применением QTextCodec, ага. Вообще, такое ощущение, что начиная с C++14, а то и с C++11, STL дорабатывают люди, которые хотят всеми силами поддержать репутацию крестов как языка для элиты. Хотя есть разные примеры (и далеко не только Qt), что на крестах можно писать по-человечески.
Особенно трогательно в этой лапше выглядит маленький незаметный auto. Вообще его вводили как раз для лучшей читаемости. Но вот ей-богу, если в этой китайской грамоте вместо него написать <const int16_t *>, на общую кошмарную картину это не повлияет ну почти никак.
Перефразируя Булгакова, C++ — хороший язык, только вот STL его испортил…