STL или спокойные контейнеры?

Я считаю, что STL - отличное программное обеспечение, однако, если мне нужно кое-что сделать KDE или связанное с Qt программирование, тогда Qt - это то, что вам нужно. Также это зависит от компилятора, который вы используете, с GCC STL работает довольно хорошо, однако, если вам нужно использовать, скажем, SUN Studio CC, тогда STL, скорее всего, доставит вам головные боли из-за компилятора, а не из STL как такового. В этом случае, поскольку компилятор заставит вас задуматься, просто используйте Qt, чтобы избавить вас от неприятностей. Только мои 2 цента ...

Мои пять центов: Контейнеры Qt должны работать одинаково на разных платформах. В то время как контейнеры STL зависят от реализации STL. Вы можете получить другие результаты производительности.

РЕДАКТИРОВАТЬ: Я не говорю, что STL «медленнее», но указываю на эффекты различные детали реализации.
Пожалуйста, проверьте это , а затем, возможно, это .
И это не настоящая проблема STL. Очевидно, что если у вас есть значительная разница в производительности, значит, проблема в коде, который использует STL.

Если данные, с которыми вы работаете, в основном используются для управления пользовательским интерфейсом на основе Qt, то определенно используйте контейнеры Qt.

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

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

Контейнеры Qt используют идиому копирования при записи.

Помимо различия в COW, контейнеры STL гораздо более широко поддерживаются на различных платформах. Qt достаточно портативен, если вы ограничиваете свою работу «основными» платформами, но STL доступен и на многих других, менее известных платформах (например, DSP от Texas Instruments).

Поскольку STL является стандартным, а не управляется одним корпорации, в общем, есть больше программистов, которые могут легко читать, понимать и изменять код STL, и больше ресурсов (книги, онлайн-форумы, конференции и т. д.), чтобы поддержать их в этом, чем есть для Qt. Это не значит, что следует избегать Qt только по этой причине; просто, при прочих равных, вы должны по умолчанию использовать STL, но, конечно, все редко бывают одинаковыми, поэтому вы Мне придется решать в своем собственном контексте, что имеет наибольший смысл.

Что касается ответа AlexKR: производительность STL гарантирована в определенных пределах, но данная реализация может использовать зависимые от платформы детали для ускорения их STL. В этом смысле вы можете получить разные результаты на разных платформах, но это никогда не будет медленнее, чем явная гарантия (по модулю ошибок).

Контейнеры STL:

• Имеют гарантии производительности
• Может использоваться в алгоритмах STL , которые также имеют гарантии производительности
• Может использоваться сторонним C ++ библиотеки, подобные Boost
• , являются стандартными и, вероятно, переживут проприетарные решения
• . Поощряйте универсальное программирование алгоритмов и структур данных. Если вы пишете новые алгоритмы и структуры данных, соответствующие STL, вы можете бесплатно использовать то, что STL уже предоставляет.

На этот вопрос сложно ответить. Это действительно может сводиться к философскому / субъективному аргументу.

С учетом сказанного ...

Я рекомендую правило «Когда в Риме ... Делайте, как делают римляне»

Что означает, если вы находитесь в стране Qt, кодируйте, как это делают Qt'ians. Это не только для удобства чтения / согласованности. Подумайте, что произойдет, если вы сохраните все в контейнере stl, тогда вам придется передать все эти данные в функцию Qt. Вы действительно хотите управлять кучей кода, который копирует вещи в / из контейнеров Qt? Ваш код уже сильно зависит от Qt, поэтому не похоже, что вы делаете его более «стандартным», используя контейнеры stl. И какой смысл в контейнере, если каждый раз, когда вы хотите использовать его для чего-нибудь полезного,

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

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

Думаю, это зависит от того, как вы используете Qt. Если вы используете его во всем своем продукте, вероятно, имеет смысл использовать контейнеры Qt. Если вы используете его только (например) для части пользовательского интерфейса, может быть лучше использовать стандартные контейнеры C ++.