views:

212

answers:

4

In trying to get up to speed with C++ (coming from a long experience with C), I am obviously trying to do the right thing, and use as much as is standard as is possible.

However, in my readings on the matter I come accross a lot of criticism for standard things, and praise for non-standard things. For example, even the the (I assume) poorly-thought-of MFC library has features in, for example, its CString class that some folks think useful enough to cause them to continue using it despite the fact that it's (a) non-standard and (b) that it's (I assume, from the wealth of criticism) deficient in many important ways.

My question is twofold, then:

A. What libraries that are poorly-thought-of contain features that nonetheless make it worth continuing to use them, what are those features, and what's so good about them?

B. Are there "adaptor" libraries out there that simplify and/or tighten up the use of such libraries, e.g. providing nice interfaces that abstract resources leaks, adaptors that go from a non-STL library interface to a STL, and so on

As a relative newbie to StackOverflow, I'm not 100% sure that this question is sufficiently on-point, so I apologise up-front if it's too open-ended.

Thanks in advance

A: 

CString is non-standard because MFC is not cross-platform, I think. std::string() is standard, but if we use everything standard, then why MS developed MFC?

Jason
Most likely MFC and CString was developed before the STL was standardized...
bdonlan
+1  A: 

IMO the best thing about MFC is that, historically, it was available before the STL was available, and something was better than nothing.

MFC is still good, if you're writing code to be compatible with an existing MFC code base.

Apart from that there's little merit in MFC, except that it's perhaps still one of the (if not the most) obvious C++ class library for Windows.

ChrisW
I mean little merit from the point of view of learning idiomatic C++, standard C++, etc. It's a pragmatic (albeit somewhat ugly and complicated) choice if you want to write Windows UIs using C++.
ChrisW
+1  A: 

My personal grunge is with ACE. It was sort of the other way around - great idea, nothing else was available at the time for cross-platform threaded and network development in C++, wide deployment, books by the library authors, etc. But the implementation was terrible, usage patterns were complicated, almost all the useful features of C++ suppressed (or didn't exist at the time.) I think this library alone is responsible for good chunk of people thinking that C++ is hard and ugly. Very recently Boost collection started catching up with threads, ipc, and networking, so there is at least an alternative. BUT with all that said, I still think it's worth to be familiar with ACE if you are in that space since, again, way too many people use it, the ideas are good, and it can serve as great negative example for library design.

Nikolai N Fetissov
From looking at its source code I think that ACE's "problem" is that it supported many, many compilers, including compilers for embedded and real-time O/Ses, back in the days when C++ itself (or at least compilers' support for it) wasn't standard ... so ACE needed to cater to the 'lowest common denominator', the minimal subset of C++ supported by all compilers, with lots of #ifdefs etc.
ChrisW
+1  A: 

On a more general note I think one of the reasons that people stick with old, awkward and perhaps even obsolete libraries is that they have grown used to it and anything new and shiny might do the job better but are harder to grasp/understand initially. And so you stay with what is familiar and keep your productivity.

I think it is a balance between getting the job done and getting the job done "right". Somewhere in between is probably where most of us end up.

Subtwo