Зачем использовать QVector (Qt) вместо std::vector
Я очень новичок в С++ и Qt, но я очень хорошо разбираюсь в С#/Java.
То, что мне нравится, кросс-платформенный, но я путаюсь с Qt. Разве не std::vector
уже кросс-платформенный, не Qt обеспечивает эквивалент без кроссплатформенной вещи?
Также как отличаются File
и QFile
?
Ссылка была бы приятной, спасибо:)
Ответы
Ответ 1
Эта статья выглядит хорошо. Он сравнивает библиотеку шаблонов Qt со стандартной библиотекой шаблонов:
Надеюсь, вам будет интересно увидеть все различия, перечисленные в этой статье.
РЕДАКТИРОВАТЬ:
Вот что я нахожу интересным:
Мое мнение таково, что самое большое преимущество QTL заключается в том, что он имеет одинаковую реализацию (включая двоичную совместимость) на всех ОС, поддерживаемых Qt. Некоторые реализации STL могут быть ниже номинальной, если речь идет о производительности, или они могут отсутствовать. Некоторые платформы даже не имеют STL! С другой стороны, STL более настраиваемый и доступен полностью в заголовочных файлах... Как я уже сказал, нет явного победителя.
Как он сказал, нет явного победителя. Но все же чтение статьи проясняет многое. Лучше знать разницу, чем идти за одним, не зная другого.
Ответ 2
Класс QVector подсчитывается по ссылке и предназначен для совместного использования без копирования. Qt предоставляет множество контейнеров, соответствующих контейнерам STL. Документ, который описывает их с некоторым объяснением внутренних элементов и немного обоснования:
Ответ 3
От здесь:
Qt происходит от времени, когда С++ и стандартная библиотека не была стандартизированы или хорошо поддерживаются компиляторы. Поэтому он дублирует много вещей, которые сейчас находятся в стандартная библиотека, такая как контейнеры и информацию о типе. Наиболее значительно, они модифицировали С++ языка для предоставления сигналов, так что Qt-классы не могут быть легко использованы с не-Qt-классы.
Ответ 4
С++ std::vector
является кросс-платформенным, поскольку он является частью стандарта С++. Каждый компилятор, совместимый с С++, должен предоставить его.
Я не знаком с Qt, но я видел это в документах:
Примечание. Все функции этого класса возвратный.
Вероятно также (предположение), что класс QVector более легко интегрируется для хранения объектов Qt-centric, чем std::vector
. Опять же, я не знаком с Qt, поэтому вам нужно решить для себя.
Как правило, для многих исключений, я бы предпочел использовать std::vector
, если у меня не было убедительной причины использовать какой-то конкретный контейнерный класс.
Ответ 5
Плохой опыт, который у меня был с QTL
, был связан с QTL
, не создающим каких-либо исключений; это затрудняет отслеживание и устранение критических ошибок. Кроме того, реализации STL
тесно связаны с компилятором, потому что для части библиотеки требуются расширения, специфичные для компилятора, для языка. Это означает, что реализация STL
может часто превосходить QTL
, которая должна быть переносимой и, следовательно, не может воспользоваться указанными расширениями. Проблема отладки была для меня очень важна.
Ответ 6
Поскольку ни один ответ не упоминал об этом, контейнеры Qt, включая QVector
обычно имеют более полный API, который обеспечивает определенное дополнительное удобство и уменьшает многословность по сравнению с std::vector
.
QVector
самом деле не интегрирован в API Qt, эту роль играет несоответствующий QList
, поэтому это не очень сильный аргумент в пользу использования QVector
для общей лучшей совместимости с API Qt. Обратите внимание, что это может измениться для Qt 6, так как недостатки QList
становятся все более и более признанными.
При этом, если вы уже зависите от Qt для своего приложения, было бы разумно использовать QVector
для удобства. Я предполагаю, что никто не собирается добавлять такую раздутую зависимость как Qt только для контейнера или двух. QVector
эффективен и надежен, и без проблем будет работать на любой платформе, поддерживаемой Qt.
С другой стороны, если вы хотите создать API-интерфейс ядра логики, не зависящий от фреймворка, было бы неплохо разработать его в стандарте C++, если это возможно, чтобы вы получили что-то переносимое, не привязанное к конкретному графическому интерфейсу. Framework, так что вы можете легко перенести его на другой в будущем, если вам нужно.