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

Question

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

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

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

Answer 1

Ronald Laeremans, VC++ менеджер Единица продукта, даже said to use STL в июне 2006 года:

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

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

Ronald Laeremans
обязанности Продукт-менеджер Блок
Visual C++ Team

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

Answer 2

Фактически you can use STL algorithms on some of MFC containers as well. Однако STL-контейнеры предпочтительны для другой очень практичной причины: многие сторонние библиотеки (Boost, arabica, Crypto ++, utf-cpp ...) предназначены для работы с STL, но ничего не знают о контейнерах MFC.

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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

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

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

Answer 10

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

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

Answer 11

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

Answer 12

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

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

Answer 13

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