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)

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

rumgot ★★★★★
()

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

anonymous
()

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

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

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

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

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

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

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

therealcherepaha
() автор топика

Тебе русские буквы нужно или 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)
Ответ на: комментарий от fsb4000

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

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

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

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

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

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

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

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

vs19 setlocale(LC_ALL, «rus»)

На винфак.

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

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

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

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

прямо в glibc'е.

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

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

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

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

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

🤦🤦🤦🤦🤦🤦🤦🤦

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

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

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

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

char32_t тогда уж

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

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

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

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

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

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

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

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

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

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

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

man LGPL

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

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

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

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

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

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

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

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

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

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

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

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

запускаю в vs19

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

intelfx ★★★★★
()

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

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

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

anonymous2 ★★★★★
()

Хранить исходники в 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 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.