Тут недавно затрагивался вопрос стандартных и кутэшных контейнеров Было высказано

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

Решил погуглить альтернативное мнение
Нагуглил ответ на этот вопрос

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

Человек в ответе говорит про взаимодействие с апи, причём разбивает это на несколько аргументов за
А остальное особо не впечатляет

Какой итог этому можно подвести?

"Используйте фреймворки, а не женитесь на них".

Ну тому же QString аналога в STL в общем-то нет Но, в отличие от, например, юникодной стринги раста, QString плох использованием UTF-16

Вообще я затрагивал эту тему в моём семинаре, где-то у нас была тут даже презентаха... Есть и видео, но оно такого страшного качества что туши свет. Ну и можно на эту тему посмотреть видео Джузеппе Д'Анжело, с CppCon. Оно простаннее и не только на эту тему, зато качество гут.

спасибо

Ещё раз, официальная позиция Qt - не надо в программе использовать контейнеры Qt, если этого не требует взаимодействие с самой библиотекой Qt.

Там вроде тесты были Было бы интересно сравнение с Qt 6

Тесты не интересны, если ты о производительности. КОнтейнеры Qt и STD обладают разными свойствами, они не взаимозаменяемы безусловно.

Ну, тут скорее интересны преимущества (или недостатки) новой реализации перед старой

Вот это да, QString совсем другой, без него как без рук, но это не совсем контейнер. Это строка.

Std::string-у до qstring как до луны пешком.. и это очень огорчает когда приходится писать чистый c++ код без qt

С этим никто не спорит.

Скажем прямо: не "как до Луны", а "задачи другие"

А в чем другие? И то и то строка..

Майбах и УАЗик - тоже машины, и ещё вопрос, где в какую сесть. std::string прочно заняла место крайне быстрой байтопомойки плюс совместимость с Си-строками

Совместимость с C в смысле возможность вернуть const char * c_str?

Но удобная строка в 2021 - это совсем не о std::basic_string, факт

Да, без лишних аллокаций и конвертаций

И как это должно выглядить с точки зрения байтопомоек нулевых символов и С-строк? ;)

Если мне требуется работать с API OS, принимающим char*/wchar_t*, замены std'шной строке нет :) А вопроса не понял, если честно

Ну про байтопомойку это не я сказал.. в моем представлении байтопомойка это массив произвольных байт, а null terminated string это отдельная история.. для легких Latin1 строк в Qt есть соотвествующий класс кстати

Проблемы винды с wchar_t* он всё ещё не решит :)

Ну у QString есть соотвествующий метод ;)

Соглашусь, пожалуй. Хотя лишний байт не так критичен, как отсутствие resize_uninitialized

А в WinAPI есть чудо вида GetData(wchar_t* buf, unsigned long len, unsigned long* written). Чо делать-то?

Оно хоть что делает? ;) типа вернуть до N wchar_t и сколько в результате получилось?

Пишет до len байт и во written возвращает нужный размер; len может быть 0, buf - нет

QString для юникода, std::string - для быстрых и компактных строк однобайтовых или двух или 4хбайтовых символов.

Зачем эта каша.. есть QLatin1String