MFC и STL

Вы бы смешали MFC с STL? Почему?

Ответ 1

Конечно. Почему бы и нет?

Я использую MFC в качестве уровня представления, хотя структуры и классы в back-end используют STL.

Ответ 2

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

Ответ 3

Я смешиваю их все время. Единственным незначительным PITA была сериализация - контейнеры MFC (CArray, CList, CStringArray и т.д.) Поддерживают сериализацию CArchive, но при использовании контейнеров STL вам необходимо свернуть собственный код. В итоге я переключился на использование boost::serialization и сбросил материал MFC CArchive.

Ответ 4

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

Ответ 5

Я использую MFC для всех моих проектов на С++, поскольку ни один из моих проектов не является консольным. MFC - изящное решение для разработчиков Windows С++. Я ненавижу QT, и я не использую WX в Windows. Я не забочусь о переносимости, так как мои приложения предназначены только для Windows. Мне нравится класс MFC/ATL CString, std::string очень сырой, в нем нет никаких функций "String". std::string - не более чем vector<char>.

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

Ответ 6

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

Ответ 7

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

Ответ 8

Да, если выполняются оба следующих условия:

1) Язык, выбранный для проекта, - это С++ (который, конечно же, включает STL - S в STL для "Standard" ).

2) После тщательного анализа лучшей альтернативы не обнаружено и не считается подходящей для поддержки GUI, чем MFC, и моя команда разработчиков идет на это.

Ответ 9

Это была очень плохая идея, прежде чем Visual Studio 2003 (почти) полностью поддерживала стандарт С++. Теперь это совсем не плохая идея. Является ли это хорошей идеей, зависит от контекста и того, что является набором навыков вашей команды.

Ответ 10

Это зависит от того, каково ваше определение "смешивания". Если вы просто хотите создать проект, который использует как STL, так и MFC, я вообще не вижу в этом никакого вреда. Они служат другой цели.

Ответ 11

при смешивании STL с другими заголовками Microsoft, обязательно определите NOMINMAX, в противном случае ваша функция std:: min будет искажена в синтаксическую ошибку из-за макроса min (a, b).

Ответ 12

Вы не должны использовать стандартные исключения в приложении MFC - ваше приложение может зависать, если вы выбросите его в диалоговом окне. См. Этот вопрос по причинам: Почему приложение MFC зависает, когда я выкидываю исключение?

Ответ 13

У меня была структура со многими простыми типами полей (UINT, CString, COLORREF и т.д.). Проект хорошо компилировался.

Затем я добавил a, в который я добавил CArray в структуру. Он не компилировался.

Затем я применил оператор = и конструктор копирования для этой структуры (один с другим). Затем он скомпилирован.

Некоторое время спустя, выполняя техническое обслуживание структуры, я сделал эксперимент: измените CArray как std::vector и удалите конструктор operator = и copy. Он скомпилирован отлично, и структура была хорошо скопирована там, где вызывались оператор = или конструктор копирования.

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

ПРИЧИНА:

Почему мне теперь не нужен оператор-копир и оператор присваивания =

Раньше структура имела только простые поля типа. Таким образом, они были гибкими. Будучи всеми из них гибкими, делает структуру гибкой. Когда я добавил поле CArray, это не было поддающимся копированию, потому что CArray происходит от CObject, класса, который explicilty делает эти две функции частными:

class AFX_NOVTABLE CObject
{
    //...

    private:
        CObject(const CObject& objectSrc);              // no implementation
        void operator=(const CObject& objectSrc);       // no implementation

    //...
}

И CArray, являющийся классом, производным от CObject, не делает ничего, чтобы переопределить это поведение, поэтому CArray наследует его и делает его незаменимым. Добавив CArray, прежде чем сделать мою структуру гибкой, я получил ошибку:

c:\program files\microsoft visual studio 8\vc\atlmfc\include\afxtempl.h(272) : error C2248: 'CObject::operator =' : cannot access private member declared in class 'CObject'
    c:\program files\microsoft visual studio 8\vc\atlmfc\include\afx.h(554) : see declaration of 'CObject::operator ='
    c:\program files\microsoft visual studio 8\vc\atlmfc\include\afx.h(524) : see declaration of 'CObject'
    This diagnostic occurred in the compiler generated function 'CArray<TYPE,ARG_TYPE> &CArray<TYPE,ARG_TYPE>::operator =(const CArray<TYPE,ARG_TYPE> &)'
    with
    [
        TYPE=unsigned int,
        ARG_TYPE=unsigned int &
    ]

std::vector можно копировать по собственному определению:

        // TEMPLATE CLASS vector
template<class _Ty,
    class _Ax = allocator<_Ty> >
    class vector
        : public _Vector_val<_Ty, _Ax>
    {   // varying size array of values
public:
    typedef vector<_Ty, _Ax> _Myt;

Замечание _Myt - это typedef для самого векторного класса.

    //...

    vector(const _Myt& _Right)
        : _Mybase(_Right._Alval)
        {   // construct by copying _Right
        if (_Buy(_Right.size()))
            _TRY_BEGIN
            this->_Mylast = _Ucopy(_Right.begin(), _Right.end(),
                this->_Myfirst);
            _CATCH_ALL
            _Tidy();
            _RERAISE;
            _CATCH_END
        }

    //...

    vector(_Myt&& _Right)
        : _Mybase(_Right._Alval)
        {   // construct by moving _Right
        _Assign_rv(_STD forward<_Myt>(_Right));
        }

    _Myt& operator=(_Myt&& _Right)
        {   // assign by moving _Right
        _Assign_rv(_STD forward<_Myt>(_Right));
        return (*this);
        }

    //...
 }

Итак, добавление поля элемента std::vector в struct/class не потребует, чтобы вы реализовали внутри него функции копирования только из-за этого нового поля.

Ответ 14

Я предпочитаю избегать STL и не использовать его, потому что он был не таким стандартным, когда MFC был де-факто стандартным в течение примерно десятилетия. Кроме того, до недавних версий Visual С++ (и "стандартного" STL), MFC имеет лучшую производительность.