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

Question

Раньше я использовал классы коллекции MFC, такие как CArray и CMap. Через некоторое время я переключился на контейнеры STL и некоторое время использовал их. Хотя я считаю STL намного лучше, я не могу точно определить точные причины этого. Некоторые из рассуждений, таких как:

1. Требуется MFC: не поддерживается, потому что другие части моей программы используют MFC
2. Это зависит от платформы: не выполняется, потому что я запускаю свое приложение только в Windows. (Нет необходимости в переносимости)
3. Это определено в стандарте C ++: ОК, но контейнеры MFC все еще работают

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

Answer 1

Рональд Лереманс, менеджер отдела продуктов VC ++, даже сказал, что использует STL в июне 2006 года:

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

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

Рональд Лереманс
и.о. руководителя отдела продукции
команда Visual C ++

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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

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