Допустим у меня есть такой код:


Будучи сохранённым в файл в кодировке utf-8 with BOM в MSVC первая строка в кодировке local-8bit, а вторая строка - utf-8. Конечно, речь идёт о времени исполнения приложения.

Вопрос: что будет с этим файлом в случае Windows+MinGW и Linux+GCC? В какой кодировке стоит сохранять файлы для кроссплатформенной совместимости?

Ну вообще да. Именно в связке с Qt. Но там же вроде GCC...

Это было бы идеально. Но... использование подобных инструментов резко повышает муторность разработки, а гибкость в создании локализаций мне не нужна. UTF-8 нужен что бы строки передавать в интерфейсы Qt. Он понимает только UTF-8. Можно, конечно, каждый раз преобразовывать средствами самого Qt.

Вообще эти проблемы с кодировками бесят неимоверно, какое-то болото на ровном месте.

Т.е. с такой кодировкой исходников у меня будет и utf-8 и однобайтовые строки в любом окружении? Windows/Linux + MinGW/GCC в любых допустимых их вариациях? Отлично спасибо. :) Вы меня успокоили.

То есть, находишь опечатку и ставишь пересобирать - норм. Заюзать попсовый gettext - не норм.
Имею большой опыт работы с подобной системой локализации от Qt. Я проклял всё... тогда. :)
Вообще эти проблемы с кодировками бесят неимоверно, какое-то болото на ровном месте.
Ты думаешь я тебе втираю тут про ascii от хорошей жизни?[/quot]
Это-то я понимаю.

Я спрашивал в каком формате мне файлы кодировать, что бы при задаче (вполне вероятной) портировать на Linux (или на MinGW) мне не пришлось всю программу переписывать. Ответ я получил: файлы исходников в кодировке utf-8 with BOM.

И всё. :)

А что такого Майкрософт разработала? UTF-16? BOM? Я просто не в курсе.

И уж точно не майкрософт разработала язык в котором восемь строковых типов и отсутствуют инструменты работы с "супер" кодировкой utf-8:



Мне иногда кажется, что мы наблюдаем закат C++. Особенно я в этом уверился когда комитет определил std::byte как strong enum...

Ты не знаешь что из себя представляет utf-8, а виноваты клятые крестовики.
В теории знаю, там ничего сложного. Я вчера гуглил и везде советуют использовать сторонние библиотеки: ICU или utfcpp. Или писать свои костыли. В библиотеках ICU и utfcpp наверняка тоже свои велосипеды и костыли типа QString.

Особенно меня убило, что они std::mblen() сделали *не* потокобезопасной или заторможенной из-за скрытого использования TLS.

Что я делаю не так?

И что ты собрался им мерить?
Он возвращает длину текущего многобайтового символа. В байтах.


Конечно везде советуют сторонние библиотеки. Плюсы предоставляют инструменты для работы с кучей байт. Символы utf - это не байты. Длинна символа может быть от 1 до 4 байт, там могут быть еще всякие модификаторы и прочие подводные камни.
Я это знаю уже лет 10-ть.

Вот это меня и раздражает, что в 2019-м году, после стольких лет развития, С++ не предоставляет возможности работать со строками, а только с кучей байт работает! Что я должен подключать какое-то стороннее велосипедирование с произвольным уровнем кривизны. Завтра это костылирование перестанут поддерживать и что тогда?


Нет, конечно.


Ссыш против ветра. Ты пишешь под кутэ? Вот и юзай его фишки. А utfcpp - вообще header-only, какие проблемы? Но нет, надо жрать кактус с wchar*/wstring и ныть о том, какие все му**ки.
На Qt я пишу только GUI. А логику на С++. А utfcpp - это сторонний костыль.

Кстати, QString тоже использует utf-16. Почему я не могу использовать wchar_t?