Sign in to follow this  
trevaaar

Some classes in MFC seem a bit redundant...

Recommended Posts

I was working on an old project that uses MFC in Visual C++ 6 (no, I can't use .NET to work on this, because the others involved are all still using 6) and I noticed it used some classes from the MFC library that seem like yet another implementation of the things already available in the standard C++ library. For example, I see CString floating around in almost every place that a string is used... What happened to std::string? There's also a CArray (like a std::vector) and a CList (like a std::list). Why are they there and why would anyone prefer them over the standard library?

Share this post


Link to post
Share on other sites
Those classes more or less predate the formation of the standard library. For example, I don't think Stepanov (the creator of the STL) had even started work on the STL when CArray was first released in MFC. Basically you wouldn't want to use them in new projects that don't use MFC.

Share this post


Link to post
Share on other sites
Exactly what SiCrane said.

MFC 1.0 came out in 1992! Remember that C++ was standardized in 1998. So when MS wrote MFC the C++ compilers were not like the ones we have today, and many of the modern C++ features we use today were at that time only in the experimental stage.

So of course it made sense for MS to make their own CString class instead of using *char. Besides, the CString class is actually not that bad.

Share this post


Link to post
Share on other sites
Actually, there's some aspects of CString that I vastly prefer to std::string - most notably the fact that CString doesn't stubbornly pretend that letters don't come in upper and lower cases. The implicit decay-to-character-pointer operator is handy, too, and I've been known to throw a similar operator into my code for std::strings when I get sick of typing .c_str().

Aside from that, though, SiCrane said it all - if you're not chained to MFC already, prefer the STL versions whenever possible. However, whichever one you choose, please for the love of God be consistent. It is exceedingly painful to maintain a project that uses MFC in half of the codebase and STL in the other half, with a thick and obscure (not to mention leaky and inefficient) wrapper layer translating between the two.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this