Почему контейнеры STL предпочтительнее контейнеров MFC?

Ответ 1

Ronald Laeremans, VС++ Product Unit Manager, даже сказал использовать STL в июне 2006 года:

И, честно говоря, команда даст вам тот же ответ. Классы коллекции MFC доступны только для обратной совместимости. С++ имеет стандарт для классов коллекции, а это библиотека стандартов С++. Нет никакого технического недостатка для использования какой-либо стандартной библиотеки в приложении MFC.

Мы не планируем вносить существенные изменения в эту область.

Рональд Лэреманс
Управляющий программным подразделением
Visual С++ Team

Однако в какой-то момент, когда я работал над некоторым кодом, который выполнялся на этапе установки Windows, мне не разрешалось использовать контейнеры STL, но мне сказали использовать контейнеры ATL (на самом деле CString в частности, что Я думаю, это не контейнер). Объяснение состояло в том, что контейнеры STL имели зависимости от битов выполнения, которые на самом деле не могли быть доступны в момент выполнения кода, в то время как эти проблемы не существовали для коллекций ATL. Это довольно специальный сценарий, который не должен влиять на 99% кода.

Ответ 2

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

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

Ответ 3

• Совместимость с другими библиотеками (например, boost) в синтаксисе, взаимодействии и парадигме. Это нетривиальная выгода.
• Использование STL разработает набор навыков, который, скорее всего, будет полезен в других контекстах. MFC не так широко используется; STL.
• Использование STL разработает мышление, которое вы можете (или не можете) найти полезным в коде, который вы пишете сами.

Использование чего-то другого, кроме STL, по своей сути является неправильным.

Ответ 4

• STL имеет больше типов коллекций, чем MFC
• Отладчик Visual Studio (2008+) визуализирует STL намного лучше, чем MFC. (магия AUTOEXP.DAT может это исправить, но это боль! Ничто не похоже на отладку вашего отладчика, когда вы его привинчиваете...)

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

Ответ 5

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

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

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

Ответ 6

Фактически вы также можете использовать алгоритмы STL на некоторых контейнерах MFC. Однако STL-контейнеры предпочтительны для другой очень практичной причины: многие сторонние библиотеки (Boost, arabica, Crypto ++, utf-cpp...) предназначены для работы с STL, но ничего не знают о контейнерах MFC.

Ответ 7

Контейнеры MFC от CObject и CObject имеют оператор присваивания, закрытый. Я нахожу это очень раздражающим на практике.

std::vector, unlinke CArray, гарантирует, что блок памяти смежный, поэтому вы можете легко взаимодействовать с C-интерфейсами программирования:

std::vector<char> buffer; 
char* c_buffer = &*buffer.begin();

Ответ 8

Предполагается, что разработчики С++, по крайней мере, знакомы с STL. Не так для контейнеров МФЦ. Поэтому, если вы добавите нового разработчика в свою команду, вам будет легче найти того, кто знает STL, чем контейнеры MFC, и, таким образом, сможет внести немедленный вклад.

Ответ 9

Я думаю, это сводится к простому вопросу: кому вы доверяете больше? Если вы доверяете Microsoft, продолжайте использовать варианты MFC. Если вы доверяете отрасли, используйте STL.

Я проголосую за STL, потому что код, который работает в Windows сегодня, возможно, придется портировать на другую платформу завтра.:)

Ответ 10

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

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

Если вы уверены, что ваш код останется в MFC-land, а контейнеры MFC будут работать для вас, почему бы не продолжать их использовать?

Контейнеры STL по своей сути лучше, чем контейнеры MFC, однако, поскольку они являются частью стандарта, они более полезны в более широком диапазоне контекстов.

Ответ 11

Поскольку библиотека, использующая итераторы, объединяет последовательности любого типа с алгоритмами, так что A) все разумные перестановки возможны и B) она универсально расширяема, (когда вы думаете о своей концепции контейнерной библиотеки, поскольку это было 15 лет назад) такая умопомрачительная идея, что она в значительной степени вылетела из воды все остальное менее чем за десять лет?

Серьезно, у STL есть свои недостатки (почему бы не диапазоны вместо итераторов?), и что стирать-удалить идиому не совсем красиво), но она основана на блестящей идее, и есть очень веские причины, по которым нам не нужно изучать новая библиотека контейнеров/алгоритмов каждый раз, когда мы начинаем работу с новой работы.

Ответ 12

Рядом с упомянутыми аспектами: хорошо поддержанный, стандартный доступный, оптимизированный для производительности, разработанный для использования с алгоритмами, я мог бы добавить еще один аспект: безопасность типов и множество проверок времени компиляции. Вы даже не можете представить рисунок double из std::set<int>.

Ответ 13

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

Я думаю, что другая причина для рассмотрения STL заключается в том, что его дизайн и эволюция выиграли от уже представленных библиотек, включая MFC и ATL. Таким образом, многие из решений являются более чистыми, более пригодными для повторного использования и менее подвержены ошибкам. (Хотя я бы хотел, чтобы у них было лучшее соглашение об именах.)