One of issues that bother me in 'Visual C++' forum is when somebody open a thread like for example "I've got a question about CArray/CList/CStringArray/etc..." and often this answer comes: "Why don't you use std::vector/std::list? It's more powerfull...".
I always said "although, theoretical there is nothing wrong, once you are using MFC, it's not a brilliant idea to mix another stuff (like STL) if it's not absolutely necessary... it makes the application harder to read, maintain, etc".
No way to convince everybody... "std::vector has copy ctor, CArray has not, std::list have sort and other cool methods which CList has not, and blah-blah..."
Well in an MFC real application, me personal, I don't remember a situation to be really necessary to directly sort a collection class elements. Most of these comes from a database and no sweat to add an "ORDER BY" to SQL statement.
Or are strings needed to be ordered in a listbox/combobox, then we have LBS_SORT/CBS_SORT styles.
Or need to sort columns in a listview control and have CListCtrl::SortItems.
And generally what sense has sorting (or copy ctors/assignment operators) for windows, GDI objects,...?
To make STL-in-MFC-mixers, speak now or be silent forever...
would be great if implement also in some MFC collection classes some features "borrowed" from STL. For sure CStringList::Sort, CStringArray::Sort, CUIntArray::Sort, CStringList::Unique, etc have sense and there is no sweat to be implemented.
Moreover, since STL has no "direct" method 'vector::sort', we'll see MFC it's more powerful .
And who knows, maybe a CAlgorithm class...
Last edited by ovidiucucu; June 20th, 2006 at 06:17 AM.
Use of standard containers in MFC applications has not only to do with availability of comfortable use with std-algorithms, but often has a lot to do with the deficiencies of the MFC container classes themselves. Take CArray for instance... This is a MFC container class with neither a copy constructor nor an assignment operator. This makes CArray really incomplete, and a programmer who chooses std::vector instead of CArray is really not to blame.
So, other than the fact that CArray carries the MFC brand to it, I see no reason why programmers should stick to using CArray - even in a MFC application, and no reason chose it over std::vector which is available to a larger spectrum of programmers over a broader variety of project types.
Another reason why one finds std::vector (or standard containers) in MFC applications is that most experienced C++ programmers who come from the non-MFC world to the MFC world, or non-Windows world to the Windows world are already acquainted with std::vector and the likes. To expect them to use a class like CArray that has it's evident shortcomings needs more reason other than "It is a MFC Class, so use it in a MFC Project".
If one looks at the picture from their perspective - it gets easier to understand why std-containers are often chosen over MFC containers.
Last edited by Siddhartha; June 20th, 2006 at 07:16 AM.
And frankly the team will give you the same answer. The MFC collection classes are only there for backwards compatibility. C++ has a standard for collection classes and that is the Standards C++ Library. There is no technical drawback for using any of the standard library in an MFC application.
We do not plan on making significant changes in this area.
Acting Product Unit Manager
Vsual C++ Team