"Отставание" Qt от Cxx

[Azazello]

Я не сомневаюсь, что многие, кто использует Qt сталкивались с этими проблемами, и каждый их решал для себя по своему.
Слово "проблема" здесь громкое, но постепенно начинает "нервировать".

Повторюсь, для упоротых - ЭТО говорилка, это НИ О ЧЕМ. ЭТО НЕ РУКОВОДСТВО К ДЕЙСТВИЮ. ЭТО ПРОСТО ЖЕЛАНИЕ ЧЕЛОВЕКА ПОГОВОРИТЬ.

Зная на практике историю развития Qt, не вызывает никакого сомнения, что они (создатели Qt) пошли правильным путем в своё время: создали для многих платформ независимый API, к примеру на уровне контейнеров. Но время "застоя" C++ прошло, и начиная с C++11 начал меняться и стиль программирование и подход к программированию (я про С++ независимо от boost).

И так, собственно, что напрягает:

1. QString. Отличный класс, когда его используешь внутри фреймворка. Как только выход на API ОС, одни преобразования. Да. Если вы посмотрите исходники QString он отличен - там и SSE2 и все прочее. Но std::string круче, когда нужна производительность - есть поддержка малых строк. Не заметил её в QString. Ну и конечно + у QString - плевать как бы на компилятор, QtCore обеспечивает совместимость библиотек.

2. Несовместимость int. Qt - int, std - uint (std::size_t). Понятно, что никакая модель памяти на x86(x64) не поддержит uint по контейнерам. uint - никогда не выйдете за пределы int. Ембедщики по этому поводу не парятся, т.к. они знают свои камни и точно знают что хотят, Qt там не пахнет. Но придушить статический анализ не хочется, а static_cast задолбал

3. Сами по себе контейнеры продвинутей в std - к примеру. Ей богу, не хочу пример, чтобы срача не было.

[ViTech]

1. QString. Отличный класс, когда его используешь внутри фреймворка. Как только выход на API ОС, одни преобразования. Да. Если вы посмотрите исходники QString он отличен - там и SSE2 и все прочее. Но std::string круче, когда нужна производительность - есть поддержка малых строк. Не заметил её в QString. Ну и конечно + у QString - плевать как бы на компилятор, QtCore обеспечивает совместимость библиотек.

Имхо, тут конфликт универсальности (поддержка полного набора Unicode) vs оптимальности по памяти/быстродействию. Для интернационализации нужна поддержка Unicode, для конфигов/данных может быть достаточно ASCII. Так что я сомневаюсь, что удастся избежать конвертации строк. Грубо говоря, как сейчас std::wstring <-> std::string.

[Azazello]

1. QString. Отличный класс, когда его используешь внутри фреймворка. Как только выход на API ОС, одни преобразования. Да. Если вы посмотрите исходники QString он отличен - там и SSE2 и все прочее. Но std::string круче, когда нужна производительность - есть поддержка малых строк. Не заметил её в QString. Ну и конечно + у QString - плевать как бы на компилятор, QtCore обеспечивает совместимость библиотек.

Имхо, тут конфликт универсальности (поддержка полного набора Unicode) vs оптимальности по памяти/быстродействию. Для интернационализации нужна поддержка Unicode, для конфигов/данных может быть достаточно ASCII. Так что я сомневаюсь, что удастся избежать конвертации строк. Грубо говоря, как сейчас std::wstring <-> std::string.

Тут немного не понял. Аналог std::string в Qt это QByteArray ну и конфликта std::wstring <-> std::string я не вижу. Всегда есть восприятие где ASCII, где вайд. Плевать на вайд, когда вы пишите ГУИ - вывод строки в формочке ни на что не влияет, там можно жертвовать чем угодно. Но к   примеру - вы хотите написать компилятор c++. Более чем уверен, парсер будет ASCII. Ну а комменты. А комменты компилятору не нужны, он их пропускает. Тут вопрос не в том, что вы вскормите компилятору wide, и он поймет. Внутренняя архитектура будет устроена так, что будет однобайтовые строки хавать.

Извиняюсь. Много лирики. Я  не говорю, что что-то плохо и что-то хорошо.
Спрошу по другому: а не перейти ли Qt на контейнеры и строки std?

Ну ладно. Строки еще под вопросом, но остальное может спокойно кочевать в новую ветку Qt - начиная от контейнеров, заканчивая мнопоточностью.

[m_ax]

По-моему, вы гипертрофируете проблему.. Я понимаю, если это было bottleneck место в коде.. Ну т.е. оно того стоит? Ну я, просто не в курсе..

[Azazello]

По-моему, вы гипертрофируете проблему.. Я понимаю, если это было bottleneck место в коде.. Ну т.е. оно того стоит? Ну я, просто не в курсе..

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

Но пройдёт лет 5-7 и она уже не будет такой гипертрофированной. Те же 5-7 лет назад у меня не стоял вопрос: какой контейнер использовать, Qt или std. Сейчас все изменилось.

[Igors]

Но пройдёт лет 5-7 и она уже не будет такой гипертрофированной. Те же 5-7 лет назад у меня не стоял вопрос: какой контейнер использовать, Qt или std. Сейчас все изменилось.

Думаю все зависит от того будет ли Qt заниматься/поддерживать свои контейнеры. Если нет - то рано или поздно они будут "поглощены", ну это судьба всего что прекратило развитие. А если да - беспокоиться не о чем.

3. Сами по себе контейнеры продвинутей в std - к примеру.

Моя главная проблема с Qt контейнерами - что мой отладчик не показывает их содержимое Аргументы в пользу std мне кажутся весьма неубедительными. Ну тот же QString - да по удобству использования std::string и рядом не стояло. Да бог с ним, с уникодом, попробуйте написать неск простых ф-ций-утилиток - и Вы сразу ощутите что нужных, удобных ф-ций под рукой нет, придется постоянно лезть в итераторную мудистику.

Или QList. Слышал мнение что, мол, теперь, когда есть крутой move (все чего-то "мувят") QList уже ничего не дает, только оверхед. Позвольте, а как хранить неперемещаемые данные? Насколько мне известно, какой-то "официальной" альтернативы в std нет, придется использовать вектор указателей. Это далеко не так удобно, хотя, справедливости ради, и предоставляет больше возможностей

[ViTech]

Имхо, тут конфликт универсальности (поддержка полного набора Unicode) vs оптимальности по памяти/быстродействию. Для интернационализации нужна поддержка Unicode, для конфигов/данных может быть достаточно ASCII. Так что я сомневаюсь, что удастся избежать конвертации строк. Грубо говоря, как сейчас std::wstring <-> std::string.

Тут немного не понял. Аналог std::string в Qt это QByteArray ну и конфликта std::wstring <-> std::string я не вижу.

Я к тому, что вряд ли будет один класс строки, который удовлетворит все потребности, поэтому конвертаций (std::wstring <-> std::string) не избежать. И тут может уже не так важно будет, переводить std::string в std::wstring или в QString. Конечно, чем меньше зоопарк - тем лучше, но, в то же время, не в ущерб функциональности и оптимальности.

[Azazello]

Ну тот же QString - да по удобству использования std::string и рядом не стояло. Да бог с ним, с уникодом, попробуйте написать неск простых ф-ций-утилиток - и Вы сразу ощутите что нужных, удобных ф-ций под рукой нет, придется постоянно лезть в итераторную мудистику.

Как хорошо, что вы перешли в практическую плоскость.
Но тут про удобство я вообще не понял. Какую сторону вы топите - QString или std и где и в чем заключается удобство.

Или QList. Слышал мнение что, мол, теперь, когда есть крутой move (все чего-то "мувят") QList уже ничего не дает, только оверхед. Позвольте, а как хранить неперемещаемые данные? Насколько мне известно, какой-то "официальной" альтернативы в std нет, придется использовать вектор указателей. Это далеко не так удобно, хотя, справедливости ради, и предоставляет больше возможностей

Вообще не понял. Т.е. смысл понятен, но интерпретаций с моей стороны куча.
Давайте уберем свистелки - перделки, которые мы засовываем в контейнеры - аля чето-там с гуи или свои пару значений. Мы ими пользуемся (контейнерами) по удобству (в данном случае), а не по функционалу. Ну если мне удобней map использовать для своих пару значений, чего я буду выслушивать крики что: "вектор или лист быстрее будет". Да это вообще не имеет значение.

Итак, свистелки откинули, более "большие" массивы - т.е. алгоритмы.
И тут мы приходим к следующему - те, кто пишет реальные алгоритмы они пытаются сделать структуры данных как раз не перемещаемые - т.е. нету там указателя на внутренние данные, яркий пример std::string, где большинство строк влазит во внутреннюю структуру. Ведь вызов new/delete мало того, что требует ресурсов, так ещё и располагает данные неизвестно где в памяти, а не рядом.

List, не смотря на теоретическое очевидное преимущество в производительности на практике сливает вектору.
И даже копирование данных в векторе, расширение вектора во многих случаях лучше чем лист.
Связано с 2 вещами:
1. Вектору не нужно заниматься выделением памяти (кроме рассширения). Аля стек по сравнению с кучей.
2. Данные, которые хранятся в векторе (если это не поинтеры) расположены рядом, и кеш проца просто отлично с ними работает.

Но,  конечно, это накладывает ограничения: данные живут в векторе, он их владелец. НО! на то они и алгоритмы, чтобы работать с массивами данных, а получать оттуда ссылки.

В принципе, разверните, что вы хотели сказать, может я не в ту степь пошёл и пишу "бред".

[m_ax]

Аргументы в пользу std мне кажутся весьма неубедительными. Ну тот же QString - да по удобству использования std::string и рядом не стояло. Да бог с ним, с уникодом, попробуйте написать неск простых ф-ций-утилиток - и Вы сразу ощутите что нужных, удобных ф-ций под рукой нет, придется постоянно лезть в итераторную мудистику.

<boost/algorithm/string.hpp> перекрывает QString

[Igors]

Какую сторону вы топите - QString или std и где и в чем заключается удобство.

Никого не "топлю"  , просто говорю что мне QString куда удобнее. Ну хотя бы нужно "обрезать" альфа-символы в начале и конце строки. Это не так уж просто с std::string. Поиск, замена и многое другое в QString намного лучше, просто больше полезных вещей (ну или "плюшек"). А не хотите плодить строки (всякий раз выделять память) - есть отличный класс QStringRef

<boost/algorithm/string.hpp> перекрывает QString

Даже если бы и так - о том что std::string он "тем более перекрывает" Вы конечно благоразумно умолчали 

1. Вектору не нужно заниматься выделением памяти (кроме рассширения). Аля стек по сравнению с кучей.
2. Данные, которые хранятся в векторе (если это не поинтеры) расположены рядом, и кеш проца просто отлично с ними работает.

Но,  конечно, это накладывает ограничения: данные живут в векторе, он их владелец. НО! на то они и алгоритмы, чтобы работать с массивами данных, а получать оттуда ссылки.

Достоинства вектора никто не умаляет, он самый популярный контейнер, и в любом проекте обязательно найдутся данные для него, рискну даже утверждать что их будет большинство. НО, помещая туда данные, мы соглашаемся с их "перемещаемостью", т.е. в общем случае адрес эл-та вектора хранить нельзя. Приходится хранить индекс, но он, в отличие от указателя, "не самодостаточен". А если еще есть вставки/удаления - то индекс вообще не годится. Короче, если данные - "хорошие" структуры, на которые ссылаются другие, то вектор не годится, тогда где их хранить? Иногда в мапе/хеше, но не всегда. Вот и выплывает идея QList, по-моему вполне разумная. Конечно можно спорить что "перемещаемо" а что нет - но сути это не меняет

[Old]

Даже если бы и так - о том что std::string он "тем более перекрывает" Вы конечно благоразумно умолчали 

Вы бы хоть смотрели, что вам предлагают.
boost/algorithm/string.hpp это алгоритмы для std::string.

[Old]

Короче, если данные - "хорошие" структуры, на которые ссылаются другие, то вектор не годится, тогда где их хранить?

Только вроде беду с const решили, а тут новая напасть... негде хранить "хорошие" структуры. Жесть.

[Azazello]

Достоинства вектора никто не умаляет, он самый популярный контейнер, и в любом проекте обязательно найдутся данные для него, рискну даже утверждать что их будет большинство. НО, помещая туда данные, мы соглашаемся с их "перемещаемостью", т.е. в общем случае адрес эл-та вектора хранить нельзя. Приходится хранить индекс, но он, в отличие от указателя, "не самодостаточен". А если еще есть вставки/удаления - то индекс вообще не годится. Короче, если данные - "хорошие" структуры, на которые ссылаются другие, то вектор не годится, тогда где их хранить? Иногда в мапе/хеше, но не всегда. Вот и выплывает идея QList, по-моему вполне разумная. Конечно можно спорить что "перемещаемо" а что нет - но сути это не меняет

Та вообще, вообще это не имеет никакого значения.
О чем мы говорим - то, что указатель теряется в векторе?
Да ребят, у нас нет алгоритмов, которые съедают куча производительности.
Вектор с миллионами записей не гуляет по программе, он спрятан. И когда вещь заходит о производительности....
О чём говорим.... Раз мы пишем на плюсах, мы автоматом пишет ++i вместо i++. Да, это хорошо, раз мы такие, но это ничего не значит.
Да, это хорошо, когда мы стараемся (плюсы обязывают) писать наиболее производительный код, даже жопой понимая, что в конкретном случае это не важно.

Но когда заходит речь реально о производительности, реальной, неужто потеря указателя важна? Да нет. Алгоритмы обрабатывают данные пакетно.
С какого бога ему нужна конкретная запись. Даже при множестве перетасовывании данных, реально действительно нужна позиция, а не конкретный объект.

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

[Авварон]

Но std::string круче, когда нужна производительность - есть поддержка малых строк.

В qt6 будет SSO. Так-то негоже ломать совместимость каждые полгода, а SSO требует нарушения BC. Почему в Qt5 не добавили, отдельный вопрос, но патч уже вроде бы тогда был.

[Igors]

О чем мы говорим - то, что указатель теряется в векторе?

О чем Вы - не знаю, а я да, об этом. Неперемещаемые данные (указатели на которые хранятся в др классах) неизбежны, и это ситуация типовая. QList решает эту проблему - и это хорошо