Mixing MFC and STL [closed] - c++

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Would you mix MFC with STL? Why?

Answer 1

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

Answer 2

Use STL whenever you can, use MFC when no alternative

Answer 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.

Answer 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.

Answer 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.

Answer 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.

Answer 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.

Answer 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.

Answer 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.

Answer 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.

Answer 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.

Answer 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?

Answer 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.

Answer 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.