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