Чистота кода

Qt ориентируется на гуи, не должно быть его в STL

http://en.cppreference.com/w/cpp/string/byte/isdigit

Notes

isdigit and isxdigit are the only standard narrow character classification functions that are not affected by the currently installed C locale. although some implementations (e.g. Microsoft in 1252 codepage) may classify additional single-byte characters as digits.

Я не занимаюсь коммерческим программированием на C++ и могу себе позволить вылизывать не «горячий» код с точки зрения производительности. Любой string который владеет своим внутренним буфером на протяжении всего времени жизни самого string в любом случае будет иметь оверхэд на ненужные копирования.

Код на результат так не пишут, и Qt там, вероятно, устраивает программистов по соотношению (результат * производительность)/гемор.

тут нет ни слова про ASCII. а вот линк поинтереснее

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18785

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

5.2.1 - ничего ни про ASCII ни про соотношение между source charset & execution charset

Любой string который владеет своим внутренним буфером на протяжении всего времени жизни самого string в любом случае будет иметь оверхэд на ненужные копирования.

const string& же

Именно utf8.

и что там с языками типа арабского, с обратной последовательностью символов?

А что с ними?

Ага, особенно QtCore, который копирует пол std.

в любом случае будет иметь оверхэд на ненужные копирования

У вас странное представление о RAII. Никто не мешает использовать implicit/explicit sharing, COW, как в Qt, и не будет никакого оверхеда.

устраивает программистов по соотношению (результат * производительность)/гемор

Просто в реальных задачах не уследить за памятью.

чтобы создать const string & из строкового литерала или из C строки, которую вернёт какой-нибудь драйвер базы, нужно сделать аллокацию памяти и скопировать строку в std::string. Поэтому для таких случаев и вводят в C++17 std::string_view.

про соотношение между source charset & execution charset

написано.

про ASCII

действительно, не написано. но я не знаю другой живой кодировки, соотв. указанному стандарту и неявляющейся надмножеством ASCII. А именно, наличие непечатаемого \0, английского алфавита и «The representation of each member of the source and execution basic character sets shall fit in a byte», «In the basic execution character set, there shall be control characters representing alert, backspace, carriage return, and new line»

EBCDIC мёртв давно

Будет оверхэд по циклам и памяти на счётчик ссылок и на создание внутненнего массива символов из C строк или любых не QT строк.

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

там всякие вектора и листы, сделанные хуже чем в стд.

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

Не написано ничего путного. Кодировка времени компиляции IBM866 и EBCDIC во время выполнения ни к чему хорошему не приведут. Но хорошо что можно проверять соответствие кодировки на совместимость с ASCII во время компиляции и смело писать код, который заточен строго под него. А рантайм поддержать можно уже каким-нибудь iconv или I/O, который заточен на тот или иной вариант репрезентации юникода.

EBCDIC жив в смысле дополнительного гемора по обеспечению сферической портабельности в вакууме на уровне исходного кода.

кстати, глянул доки раст, они противоречат вашим словам:

«Because strings are valid UTF-8, they do not support indexing»

https://doc.rust-lang.org/book/strings.html

Qt ориентируется на гуи

Опять двадцать пять...

Qt - это модульный фреймворк, в котором большинство модулей (включая гуи, разумеется) необязательны. Единственный обязательный модуль - это QtCore. И помимо GUI, там есть модули для кроссплатформенной работы с сетью, XML, БД и т.д. Если выкинуть QtGui/QtWidget, на остальном вполне можно написать сетевой сервер, например.

А что там написано?

Любой string который владеет своим внутренним буфером на протяжении всего времени жизни самого string в любом случае будет иметь оверхэд на ненужные копирования.

QString поддерживает COW.

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

EBCDIC жив в смысле дополнительного гемора по обеспечению сферической портабельности в вакууме на уровне исходного кода.

Не нужно. Текстом следует считать только то, что соответствует хотя бы какому-нибудь стандарту юникод или его подмножеству.

авторы Qt сделали то, чем могла бы стать STL

Авторы Qt постарались сделать Java из C++. Динамическая память, подсчет ссылок и позднее связывание во все поля. Естественно, это противоречит идее STL и самого C++ с его zero-cost.

только это всё либо ненужно в стд, либо сделано хуже, чем в стд

исключения строки, файлы с директориями, и вот да, работа с сетью ещё

Если вам действительно нужно считать каждую аллокацию и вы уверены, что у вас не будет невалидных указателей и утечек - то вперёд.

там всякие вектора и листы, сделанные хуже чем в стд.

Чем хуже?

Because strings are valid UTF-8, they do not support indexing

По-моему вы просто не поняли сути этой фразы.

Есть String::chars() для индексации по символам, а не байтам.

Нет, всё проще, просто авторы Qt сделали то, чем могла бы стать STL

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

Qt и STL - библиотеки. C++ - язык. Хотя вы все равно не поймете ;)

Единственный обязательный модуль - это QtCore.

Даже больше. Начиная с Qt5 QtCore умеет bootstrap версию, где выключено очень многое. Тот же qmake собирается именно с ним, статически.

именно utf8?

да, именно utf8. Поэтому нельзя индексировать по символам (это не имеет смысла в utf8), только итерировать. Если тебе так важно ходить по индексу то можешь построить массив символов и ходить по нему:

let chars = text.chars().collect::<Vec<char>>();

что там с языками типа арабского,

Вот сылка на песочницу, можешь сам посмотреть: https://is.gd/Ug6xLP

не умеет конвертится из std::initializer list, не хватает каких-то алгоритмов из stl (деталей не помню и, может, в 5-ке уже починили)

Есть String::chars()

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

QVector::push_back уже научился работать с типами без конструктора по-умолчанию?

В 5-ке есть конструктор из std::initializer_list.

Qt и STL - библиотеки. C++ - язык.

И как это противоречит тому, что я написал?

Хотя вы все равно не поймете ;)

Куда уж мне, лол.

Куда уж мне, лол.

ну хоть это ты понял)

не умеет конвертится из std::initializer list

Это как?

initializer_list начиная с 5-ки умеет

Индексация чего? Байт или символов?

без обещанного оверхеда

Какого оверхеда? При работе с utf-8 всё равно будут расходы.

Нет. Оно нужно?

Да.

COW не поддерживает передачу владения от C string к QT string без копирования.

Да. Лишь бы результат удовлетворял. Поэтому против QT ничего не имею.

Согласен, это достаточно безопасная на сегодня стратегия написания квазипортабельного кода.

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

Я об этом же. Если у вас тормоза на аллокациях - то у вас какая-то уже слишком низкоуровневая задача.

к слову, если не задана нормальная форма NFKC или NFC, то любой UTF (хоть UTF-32) не позволяет random access по символам. Codepoints - это не символы. Вот тут есть подробности:

http://unicode.org/reports/tr15/#Norm_Forms

Хорошо хоть в большинстве случаев серьёзной обработкой текстов заморачиваться не нужно.

Индексация символов

Какого оверхеда? «But, because each character in a UTF-8 encoded string can be multiple bytes, you have to walk over the string to find the nᵗʰ letter of a string. This is a significantly more expensive operation, and we don’t want to be misleading.» вот этого

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

Codepoints - это не символы.

это уже философский вопрос, что считать символом

перевод строки в ascii - это символ?

Перевод строки ('\n') в процесс разбора текста проблем никаких не приносит. А вот различные формы репрезентации в одном и том же Unicode разных там źćčšŭł - это уже интереснее. Если работать в подпространстве ASCII - то жить легко и просто в любом UTF. А если работать с Unicode текстом на любом более-менее семантическом уровне разбора «символов» - появляются нюансы.

чему равен sizeof(u32"Ščytok")?

чему равен sizeof(u"ой-ё-ёй")?

ответ - зависит от того, в какой форме сохранён этот текст.

Фигасе. Я иногда обратный эффект видел. На хабре даже комментарии были, где iostreams разгоняли лучше *f-ов.

Они сейчас активно интегрируются с C++11 и новее. Так что там не Ад и Израиль.