E-mail the author[ C++ FAQ Lite | Table of contents | Subject index | About the author | © | Download your own copy ]
Revised May 2, 2003
Yes.
C++ is a practical tool. It's not perfect, but it's useful.
In the world of industrial software, C++ is viewed as a solid, mature, mainstream tool. It has widespread industry support which makes it "good" from an overall business perspective.
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
Nope.
C++ wasn't designed to demonstrate what a perfect OO language looks like. It was designed to be a practical tool for solving real world problems. It has a few warts, but the only place where it's appropriate to keep fiddling with something until it's perfect is in a pure academic setting. That wasn't C++'s goal.
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
Object-oriented techniques are the best way we know of to develop large, complex software applications and systems.
OO hype: the software industry is "failing" to meet demands for large, complex software systems. But this failure is actually due to our successes: our successes have propelled users to ask for more. Unfortunately we created a market hunger that Structured Analysis, Design and Programming techniques couldn't satisfy. This required us to create a better paradigm.
C++ supports OO programming. C++ can also be used as a traditional programming language (as "as a better C"). However if you use it "as a better C," don't expect to get the benefits of object-oriented programming.
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
This question generates much much more heat than light. Please read the following before posting some variant of this question.
In 99% of the cases, programming language selection is dominated by business considerations, not by technical considerations. Things that really end up mattering are things like availability of a programming environment for the development machine, availability of runtime environment(s) for the deployment machine(s), licensing/legal issues of the runtime and/or development environments, availability of trained developers, availability of consulting services, and corporate culture/politics. These business considerations generally play a much greater role than compile time performance, runtime performance, static vs. dynamic typing, static vs. dynamic binding, etc.
Anyone who argues in favor of one language over another in a purely technical manner (i.e., who ignores the dominant business issues) exposes themself as a techie weenie, and deserves not to be heard.
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
Lots and lots of companies and government sites. Lots.
The large number of developers (and therefore the large amount of available support infrastructure including vendors, tools, training, etc.) is one of several critical features of C++.
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
Companies successfully teach standard industry "short courses," where a university semester course is compressed into one 40 hour work week. But regardless of where you get your training, make sure the courses have a hands-on element, since most people learn best when they have projects to help the concepts "gel." But even if they have the best training, they're not ready yet.
It takes 6-12 months to become proficient in OO/C++. Less if the developers have easy access to a "local" body of experts, more if there isn't a "good" general purpose C++ class library available. To become one of these experts who can mentor others takes around 3 years.
Some people never make it. You don't have a chance unless you are teachable and have personal drive. As a bare minimum on "teachability," you have to be able to admit when you've been wrong. As a bare minimum on "drive," you must be willing to put in some extra hours (it's a lot easier to learn some new facts than it is to change your paradigm [i.e., to change the way you think; to change your notion of goodness; to change your mental model of the world of technology]).
Two things you should do:
Two things you should not do:
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
Here are a few features of OO/C++ from a business perspective:
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
Yes!
Without virtual functions, C++ wouldn't be object-oriented. Operator overloading and non-virtual member functions are great, but they are, after all, just syntactic sugar for the more typical C notion of passing a pointer to a struct to a function. The standard library contains numerous templates that illustrate "generic programming" techniques, which are also great, but virtual functions are still at the heart of object-oriented programming using C++.
From a business perspective, there is very little reason to switch from straight C to C++ without virtual functions (for now we'll ignore generic programming and the standard library). Technical people often think that there is a large difference between C and non-OO C++, but without OO, the difference usually isn't enough to justify the cost of training developers, new tools, etc. In other words, if I were to advise a manager regarding whether to switch from C to non-OO C++ (i.e., to switch languages but not paradigms), I'd probably discourage him or her unless there were compelling tool-oriented reasons. From a business perspective, OO can help make systems extensible and adaptable, but just the syntax of C++ classes without OO may not even reduce the maintenance cost, and it surely adds to the training cost significantly.
Bottom line: C++ without virtual is not OO. Programming with classes but without dynamic binding is called "object based," but not "object oriented." Throwing out virtual functions is the same as throwing out OO. All you have left is object-based programming, similar to the original Ada language (the new Ada language, by the way, supports true OO rather than just object-based programming).
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
Dynamic binding can improve reuse by letting old code call new code.
Before OO came along, reuse was accomplished by having new code call old code.
For example, a programmer might write some code that called some reusable code
such as
With OO, reuse can also be accomplished by having old code call new code. For example, a programmer might write some code that is called by a framework that was written by their great, great grandfather. There's no need to change great-great-grandpa's code. In fact, it doesn't even need to be recompiled. Even if all you have left is the object file and the source code that great-great-grandpa wrote was lost 25 years ago, that ancient object file will call the new extension without anything falling apart.
That is extensibility, and that is OO.
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
Almost.
C++ is as close as possible to compatible with C, but no closer. In practice,
the major difference is that C++ requires prototypes, and that
There are some very subtle differences as well, like
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
Yes.
The C++ standard was finalized and adopted by ISO (International Organization for Standardization) as well as several national standards organizations such as ANSI (The American National Standards Institute), BSI (The British Standards Institute), DIN (The German National Standards Organization). The ISO standard was finalized and adopted by unanimous vote November 14, 1997.
The ANSI C++ committee is called "X3J16". The ISO C++ standards group is called "WG21". The major players in the ANSI/ISO C++ standards process include just about everyone: representatives from Australia, Canada, Denmark, France, Germany, Ireland, Japan, the Netherlands, New Zealand, Sweden, the UK, and the USA, along with representatives from about a hundred companies and many interested individuals. Major players include AT&T, Ericsson, Digital, Borland, Hewlett Packard, IBM, Mentor Graphics, Microsoft, Silicon Graphics, Sun Microsystems, and Siemens. After about 8 years of work, this standard is now complete. On November 14, 1997, the standard was approved by a unanimous vote of the countries that had representatives present in Morristown.
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
There are at least three ways to get a soft-copy of this document:
Note: The ISO document is well over ten times more expensive than the ANSI document, however the technical content is the same. The ISO document has a different title page, but the technical material is identical to the ANSI document. Please don't email asking me why ISO charges so much more for fundamentally the same thing; that's ISO's business decision; you'll have to take it up with ISO's publishing/sales department.
There are at least two ways to get a hard-copy of this document:
There are two other potentially interesting (and free) documents you might want to look at:
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
This answer is primarily for non-technical managers and HR folks who are trying to do a good job at interviewing C++ candidates. If you're a C++ programmer about to be interviewed, and if you're lurking in this FAQ hoping to know the questions they'll ask you ahead of time so you can avoid having to really learn C++, shame on you: spend your time becoming technically competent and you won't have to try to "cheat" your way through life!
Back to the non-technical manager / HR person: obviously you are eminently qualified to judge whether a candidate is a good "fit" with your company's culture. However there are enough charlatans, wannabes, and posers out there that you really need to team up with someone who is technically competent in order to make sure the candidate has the right level of technical skill. A lot of companies have been burned by hiring nice but incompetent duds — people who were incompetent in spite of the fact that they knew the answers to a few obscure questions. The only way to smoke out the posers and wannabes is to get someone in with you who can ask penetrating technical questions. You have no hope whatsoever of doing that yourself. Even if I gave you a bunch of "tricky questions," they wouldn't smoke out the bad guys.
Your technical sidekick might not be (and often isn't) qualified to judge the candidate on personality or soft skills, so please don't abdicate your role as the final arbiter in the decision making process. But please don't think you can ask a half dozen C++ questions and have the slightest clue if the candidate really knows what they're talking about from a technical perspective.
Having said all that, if you're technical enough to read the C++ FAQ, you can dig up a lot of good interview questions here. The FAQ has a lot of goodies that will separate the wheat from the chaff. The FAQ focuses on what programmers should do, as opposed to merely what the compiler will let them do. There are things that can be done in C++ but shouldn't be done. The FAQ helps people separate those two.
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
It means such-in-such is something you should avoid most of the time, but not something you should avoid all the time. For example, you will end up using these "evil" things whenever they are "the least evil of the evil alternatives." It's a joke, okay? Don't take it too seriously.
The real purpose of the term ("Ah ha," I hear you saying, "there
really is a hidden motive!"; you're right: there is) is to
shake new C++ programmers free from some of their old thinking. For example,
C programmers who are new to C++ often use pointers, arrays and/or
Now let's get real here. I'm not suggesting macros or arrays or pointers are right up there with murder or kidnapping. Well, maybe pointers. (Just kidding!) So don't get all hyper about the word "evil": it's supposed to sound a little outrageous. So don't look for a technically precise definition of exactly when something is or isn't "evil": there isn't one.
Another thing: things labeled as "evil" (macros, arrays, pointers, etc.) aren't always bad in all situations. When they are the "least bad" of the alternatives, use them!
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
Of course you will!
One size does not fit all. Stop. Right now, take out a fine-point marker and write on the inside of your glasses: Software Development Is Decision Making. "Think" is not a four-letter word. There are very few if any "never..." and "always..." rules in software — rules that you can apply without thinking — rules that always work in all situations in all markets — one-size-fits-all rules.
In plain English, you will have to make decisions, and the quality of your decisions will effect the business value of your software. And sometimes you will have to choose between a bunch of bad options. When that happens, the best you can hope for is to choose the least bad of the alternatives, the lesser of the "evils."
So you will end up using approaches and techniques labeled as "evil." If that makes you uncomfortable, mentally change the word "evil" to "frequently undesirable" (but don't quit your day job to become an author: milquetoast terms like that put people to sleep :-)
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
E-mail the author
[ C++ FAQ Lite
| Table of contents
| Subject index
| About the author
| ©
| Download your own copy ]
Revised May 2, 2003