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

Это, возможно, ошибка дизайна на Java.

class MyClass {

   // this is a constructor
   MyClass() {...}

   // this is an instance method
   void MyClass() {...}

 }

Совершенно законно. Вероятно, этого не должно быть, но есть.

В вашем примере класс1 () никогда не вызывается, потому что он не является конструктором. Вместо этого вызывается конструктор по умолчанию.

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

29
задан Ajay 27 May 2016 в 12:12
поделиться

13 ответов

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

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

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

Рональд Лэреманс
Исполняющий обязанности менеджера подразделения продукта
Команда Visual C ++

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

46
ответ дан 27 November 2019 в 22:57
поделиться

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

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

2
ответ дан 27 November 2019 в 22:57
поделиться

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

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

2
ответ дан 27 November 2019 в 22:57
поделиться

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

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

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

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

2
ответ дан 27 November 2019 в 22:57
поделиться

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

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

std::vector<char> buffer; 
char* c_buffer = &*buffer.begin();
4
ответ дан 27 November 2019 в 22:57
поделиться

I think it boils down to a simple question: Who do you trust more? If you trust Microsoft, then continue to use the MFC variants. If you trust the industry, then use STL.

I vote for STL because the code that runs on Windows today might need to be ported to another platform tomorrow. :)

3
ответ дан 27 November 2019 в 22:57
поделиться

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

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

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

7
ответ дан 27 November 2019 в 22:57
поделиться
  • Совместимость с другими библиотеками (такими как boost) по синтаксису, взаимодействию и парадигме. Это нетривиальное преимущество.
  • Использование STL развивает набор навыков, который с большей вероятностью будет полезен в других контекстах. MFC больше не используется так широко; STL - это.
  • Использование STL разовьет мышление, которое вы можете (или не можете) найти полезным в коде, который вы пишете сами.

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

22
ответ дан 27 November 2019 в 22:57
поделиться

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

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

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

4
ответ дан 27 November 2019 в 22:57
поделиться

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

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

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

6
ответ дан 27 November 2019 в 22:57
поделиться

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

разработан для использования с алгоритмами, я мог бы добавить еще один аспект: безопасность типов и множество проверок во время компиляции. Вы даже представить себе не можете, как нарисовать double из std :: set .

разработан для использования с алгоритмами, я мог бы добавить еще один аспект: безопасность типов и множество проверок во время компиляции. Вы даже представить себе не можете, как нарисовать double из std :: set .

2
ответ дан 27 November 2019 в 22:57
поделиться
Другие вопросы по тегам:

Похожие вопросы: