The well-crafted C++ library should be full-featured and complete. In this last article of his series, Hal Fulton emphasizes that the developer should also pay special attention to areas such as testing and documentation, both of which are neglected too often.
The Well-Crafted Class in C++: Part 2
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The article is excellent. I don’t think it’s for newbies. It’s good to read such things from time to time (even for advanced programmers), because you never know everything, and you can improve your coding.
I glanced through the first few sections of the article and found a couple of things that I’d like to comment on:
* operator+= should return by reference instead of by value. operator+ should return by value.
* “On the other hand, if you want to avoid the creation of a new object when += is invoked, violate this rule and duplicate the code.”
Operator+ should be implemented in terms of operator+=, not the other way around.
* Prefix operator++ should return a reference. Postfix operator++ should be implemented in terms of prefix operator++.
* “Alternatively, you could raise an exception that explicitly points out that these are not implemented.”
This is just ludicrous. The compiler will issue a compile time error if one tries to invoke an operator that doesn’t exist. C++ programmers tend to prefer compile time errors in favor of runtime errors.
* Conversion operators should be used with extreme care. The reason for this is that they will end up getting called by accident if one is not careful. Again, compile time errors are preferred to hard to find runtime errors.
Agreed, C++ developers writing real world programs should NOT read this article. Vinkelhake notes critical flaws that would result in a very strangely behaving object.
It’s obvious the author his ripped these examples from a poorly written text book or garned them from his C++ 101 class taught by an equivalently inept professor.
Note to fresh C++ students: ask your professor when he/she last wrote a real-world usable program in C++. When he or she starts deflecting the questing, you might consider memorizing the bits needed to pass the tests, while learning C++ on your own.
the points you raise are great.
seems like the quality of posted programming articles is just not what it has been. the only interesting one recently was the shared memory one–and that only because of the comments.
also, any discussion of operator overloading (and especially conversion operators!) that doesn’t at least mention explicit constructors is sorely remiss.
“while learning C++ on your own. ”
Well 3 out of 4 comments says the article is not to great. Then I have a question for them then since leaving the rest of the people who read the comments hanging?
What should one read to learn c++ on your own? What “Good” sources should one look then :-p. I mean come on, what do you think is a good book then or good articles you can point people to then. Saying the article should be avoided is good, saying where to get good knowledge is even better ;-). Just offering a suggestion, cause people got to learn somewhere.
I highly recommend Effective C++ and More Effective C++ for everybody. They teach for good C++ practices and show you want to do and what not. C++ Gotchas might also be good for intermediate programmers.
> What should one read to learn c++ on your own? What
> “Good” sources should one look then :-p. I mean come on,
> what do you think is a good book then or good articles
> you can point people to then.
I learned a lot by reading Herb Sutter’s “Guru of the week”
articles: http://www.gotw.ca/gotw/index.htm
Blech. Not my favorite article. I highly recommend Joshua Bloch’s Effective Java; best programming language book I’ve evern read (and it’s implications reach beyond Java).
Was never a fan of the _prefix for local variables in C++ and other languages. When I see that crap make it’s way into Java or C# I refactor it and commit it back =)
The article series only message is its author’s total incompetence in C++.
The ACCU (http://www.accu.org/) has a lot of book reviews that help finding good C++ literature.
If a method is called repeatedly (thousands or millions of times), make it an inline function to save the overhead of the stack manipulation. Methods declared in the class body are inline code by default.
Agonizing. For several years, compilers have been able to inline better than humans. It is incorrect (or simply sloppy) that “Methods declared in the class body are inline code by default”. Methods declared in the body are defined as if you put “inline” there, but the compiler can ignore the inline directive completely and not inline the code.
Then this:
If you define ++ and — operators, make sure that you define both forms (pre- and post-).
There are a number of good reasons to not define both forms, especially if the post-version is expensive or can mutate the state in an unexpected way. I have several iterator classes which do not have post-increment (or decrement) operators because it would violate the semantics of the object.
Sigh. Don’t get me started on the “I have to admit that efficiency is not something to which I give tremendous thought.” The advice to profile before optimizing is generally correct, but efficiency should always be something you’re thinking about, otherwise you wind up with an O(n^3) algorithm where an O(n) alg. would do. Or you block too much on a resource, etc. Most of his comments are reasonable, but “Processors are thousands of times faster than they were 30 years ago, and we don’t have to worry about it as much as we used to” is inexcusable. Because computers are so much faster, we use them differently and have more demanding requirements. And good design produces solutions that are usable on something other than the newest computer out there (unless the problem simply is too complex).
I second the Scott Meyers suggestion; and when you graduate from his stuff, look into anything by Nicolai Josuttis (especially his incredible STL book) and track down “Modern C++ Design” by Alexandrescu. Josuttis is the most practical (and heavily-used) reference I own, and Alexandrescu does things with the language you’d think weren’t possible. His “policy classes” in particular are great, and make a strong argument for multiple inheritance IMHO.
Are C++ Primer a good way to begin learning C++? If yes, then what C++ Primer do you recommend?
There are certainly flaws and arguably even errors in this
article. I do wish they had been caught sooner. The material
was reviewed by two other C++ programmers before publication.
Anything Scott Meyers writes on C++ is good. Stroustrup is
obviously an authority. I’m not familiar with Josuttis or
Alexandrescu.
As for a primer, I think there was one by Lippmann and Lajoie
that I liked a few years ago. Don’t bother with “C++ for
Morons” or the equivalent.
Thanks,
Hal Fulton