'Mixing MFC and STL [closed]

Would you mix MFC with STL? Why?

c++mfcstl


Solution 1:[1]

Sure. Why not?

I use MFC as the presentation layer, even though the structures and classes in the back-end use STL.

Solution 2:[2]

Use STL whenever you can, use MFC when no alternative

Solution 3:[3]

I mix them all the time. The only minor PITA was serialization - the MFC containers (CArray, CList, CStringArray, etc.) support CArchive serialization, but when using STL containers you have to roll your own code. In the end I switched to using boost::serialization and dumped the MFC CArchive stuff.

Solution 4:[4]

Yes, I have mixed them before without problems. However, after using MFC for over a decade, I would never consider using it for a new project.

Solution 5:[5]

I use MFC for all my C++ projects, since none of my projects are console. MFC is elegant solution for Windows C++ developers. I hate QT, and I wont use WX on Windows. I dont care about portability, since my applications are only for Windows. I love MFC/ATL's CString class, std::string is very raw, doesn't have any "String" features in it. std::string is nothing more than vector<char>.

For all data storage and algorithms, I use STL. I do also use ConcRT PPL template classes, which are very much same as STL.

Solution 6:[6]

For collections in the data layer. I have no data to support this, but my suspicion is that the templated STL collections are more performant than their MFC counterparts.

Solution 7:[7]

Yes I do mix 'em because I find MFC too unwieldy for normal natural looking c++. Though you might have to write some code for conversions where your STL code talks to MFC code.

Solution 8:[8]

It was a very bad idea before Visual Studio 2003's (nearly) full support for the C++ Standard. Now it's not a bad idea at all. Whether it's a good idea depends on the context and what the skillset of your team is.

Solution 9:[9]

Yes, if both of the following conditions hold:

1) The language chosen for the project is C++ (which, of course, includes the STL - the S in the STL is for "Standard").

2) After a careful analysis, no better alternative is found or considered appropriate for the GUI support than MFC, and my development team goes for it.

Solution 10:[10]

It depends on what your definition of "mixing" is. If you simply mean creating a project that uses both STL and MFC I don't see any harm in that at all. They serve a different purpose.

Solution 11:[11]

when mixing STL with other microsoft headers, be sure to define NOMINMAX, otherwise your std::min function will be garbled into a syntax error because of the min(a,b) macro.

Solution 12:[12]

You should not use standard exceptions in an MFC application - your app might hang if you throw it inside a dialog. See this question for the reasons: Why does my MFC app hang when I throw an exception?

Solution 13:[13]

I had a struct with many simple type fields (UINT, CString, COLORREF, etc.). Project was compiling well.

Then I added a which I added a CArray to the struct. It wasn't compiling.

Then I implemented operator= and copy constructor for that struct (one using the other). It then compiled.

Some time after, doing maintenance to the struct I did an experiment: change the CArray to be a std::vector and remove the operator= and copy constructor. It compiled fine and the struct was being well-copied where operator= or copy constructor were being called.

The advantage is that I could dump a useless part of the code — prone to errors and probably not updated when someone did maintenance adding a field to the struct! — and I see that as a big advantage.

REASON:

Why I don't need the copy-constructor and the = assignment operator now?

Before, the struct had only simple type fields. So they were copiable. Being all of them copiable, makes the struct copiable. When I added the CArray field, this one was no copiable, because CArray derives from CObject, a class that explicilty makes these two functions private:

class AFX_NOVTABLE CObject
{
    //...

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

    //...
}

And CArray, being a class derived from CObject, doesn't do anything to override this behavior, so CArray will inherit it and rendering itself uncopiable. Having added a CArray before making my struct copiable, I was recieving the error:

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 &
    ]

The std::vector is copiable by its own definition:

        // 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;

Notice _Myt is a typedef to the vector class itself.

    //...

    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);
        }

    //...
 }

So, adding a std::vector member field to a struct/class will not require you to implement copying functions inside it, only because of that new field.

Solution 14:[14]

I prefer to avoid STL and not to use it because it used to be not so standard when MFC was de-facto standard for about a decade. Also until recent versions of Visual C++ (and "standard" STL), MFC just have better performance.

Related Questions