LINUX.ORG.RU

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

 


0

2

 #include <iostream>
#include <string>
using namespace std;
int main() {
	setlocale(LC_ALL, "rus");
	string word;
	char vowels[10]{'а','е','ё','и','о','у','э','ы','ю','я'};
	getline(cin, word, '.');
	cout << word;
	
	return 0;
} 
 

 
 На ввод (это просто нечто.) оно мне выводит (нвR ЇаRбвR -?звR).
 Как это исправить подскажите.

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

ЗЫ

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

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 1)

Тебе русские буквы нужно или 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

fsb4000 ★★★★ ()
Последнее исправление: fsb4000 (всего исправлений: 2)
Ответ на: комментарий от rumgot

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

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

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

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

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

fsb4000 ★★★★ ()
Ответ на: комментарий от fsb4000

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

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

rumgot ★★★★★ ()
Ответ на: комментарий от fsb4000

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

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

rumgot ★★★★★ ()

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

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

setlocale(LC_ALL, "ru_RU_cp1251");

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

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

hobbit ★★★★★ ()
Ответ на: комментарий от fsb4000

Вот пример с 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() вылезает…

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

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

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

fsb4000 ★★★★ ()
Ответ на: комментарий от peregrine
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

🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦

fsb4000 ★★★★ ()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от peregrine

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

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

anonymous ()
Ответ на: комментарий от fsb4000

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 бита, не лезет.

ЗЫ

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

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от fsb4000

Qt

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

Ути-пути.

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

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

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

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

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

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

hobbit ★★★★★ ()
Ответ на: комментарий от bhfq

char32_t тогда уж

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

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

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 2)
Ответ на: комментарий от peregrine

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

mydibyje ()
Ответ на: комментарий от rumgot

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

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от rumgot

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

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

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

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

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

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

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

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

hobbit ★★★★★ ()
Ответ на: комментарий от peregrine

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

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

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

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1)

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());
}
maxis11 ()

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

X512 ()
Ответ на: комментарий от maxis11

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

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

hobbit ★★★★★ ()