E-mail the author[ C++ FAQ Lite | Table of contents | Subject index | About the author | © | Download your own copy ]
Revised Mar 1, 2006
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 language looks like. It was designed to be a practical tool for solving real world problems. It has a few warts, as do all practical programming tools, 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, imperative programming language ("as a better C") or using the generic programming approach. Naturally each of these approaches has its pros and cons; don't expect the benefits of one technique while using another. (Most common case of misunderstanding: don't expect to get the benefits of object-oriented programming if you're using C++ as a better C.)
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
C++ supports generic programming. Generic programming is a way of developing software that maximizes code reuse in a way that does not sacrifice performance. (The "performance" part isn't strictly necessary, but it is highly desirable.)
Generic components are pretty easy to use, at least if they're designed well, and they tend to hide a lot of complexity. The other interesting feature is that they tend to make your code faster, particularly if you use them more. This creates a pleasant non-tradeoff: when you use the components to do the nasty work for you, your code gets smaller and simpler, you have less chance of introducing errors, and your code will often run faster.
Most developers are not cut out to create these generic components, but most can use them. The process for creating them is a non-process. You fiddle, you scratch your head, you wake up a 3 a.m. with a great idea, you rip your code up over and over (and over and over). In short, you iterate. You're trying to put 10 pounds of stuff into the proverbial 5-pound bag. People who don't like to think — to solve puzzles — need not apply.
Fortunately generic components are, um, generic, so your organization does not often need to create a lot of them. There are many off-the-shelf libraries of generic components. STL is one such library. Boost has a bunch more. There are many.
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
Stop. 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. Business issues dominate technical issues, and anyone who doesn't realize that is destined to make decisions that have terrible business consequences — they are dangerous to their employer.
[ 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. Remember: 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 models.
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 updated Ada language, by the way, supports true OO rather than just object-based programming).
Note: you don't need virtual functions for generic programming. Among other things, this means you can't tell which paradigm you've used simply by counting the number of virtual functions you have.
[ 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 ]
Be prepared to spend some money — the document is not free. There are lots of ways to get it; here are a few of them in random order:
Here are a couple of related documents. They are free, but are not the standard itself.
[ 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 and 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 affect 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 ]
You might not like this, but the short answer is, "No." (With the caveat that this answer is directed to practitioners, not theoreticians.)
Mature software designers evaluate situations based on business criteria (time, money and risk) in addition to technical criteria like whether something is or is not "good OO" or "good class design." This is a lot harder since it involves business issues (schedule, skill of the people, finding out where the company wants to go so we know where to design flexibility into the software, willingness to factor in the likelihood of future changes - changes that are likely rather than merely theoretically possible, etc.) in addition to technical issues. However it results in decisions that are a lot more likely to bring good business results.
As a developer, you have a fiduciary responsibility to your employer to invest only in ways that have a reasonable expectation for a return on that investment. If you don't ask the business questions in addition to the technical questions, you will make decisions that have random and unpredictable business consequences.
Like it or not, what that means in practice is that you're probably better off leaving terms like "good class design" and "good OO" undefined. In fact I believe precise, pure-technical definitions of those terms can be dangerous and can cost companies money, ultimately perhaps even costing people their jobs. That sounds bizarre, but there's a really good reason: if these terms are defined in precise, pure-technical terms, well-meaning developers tend to ignore business considerations in their desire to fulfill these pure-technical definitions of "good."
Any purely technical definition of "good," such as "good OO" or "good design" or anything else that can be evaluated without regard to schedule, business objectives (so we know where to invest), expected future changes, corporate culture with respect to a willingness to invest in the future, skill levels of the team that will be doing the maintenance, etc., is dangerous. It is dangerous because it deceives programmers into thinking they are making "right" decisions when in reality they might be making decisions that have terrible consequences. Or those decisions might not have terrible business consequences, but that's the point: when you ignore business considerations while making decisions, the business consequences will be random and somewhat unpredicatable. That's bad.
It is a simple fact that business issues dominate technical issues, and any definition of "good" that fails to acknowledge that fact is bad.
[ Top | Bottom | Previous section | Next section | Search the FAQ ]
Tell them to grow up.
Some people want to change the word "FAQ" to a different acronym, such as something emphasizing the answers rather than the questions. However a word or phrase is defined by its usage. Multitudes of people already understand "FAQ" as a word in its own right. Think of it as a moniker for an idea rather than an acronym. As a word, "FAQ" already means a list of common questions and answers.
Do not take this as an encouragement to use words sloppily. Quite the opposite. The point is that clear communication involves using words that everybody already understands. Getting into a contest over whether we should change the word "FAQ" is silly and a waste of time. It would be one thing if the word wasn't already well known, but it no longer makes sense after so many people already understand it.
An (imperfect) analogy: the character
Another (imperfect) analogy is RAII. Thanks to the excellent work of Andy Koenig, Bjarne Stroustrup, and others, the name "RAII" has become very widely known in the C++ community. "RAII" represents a very valuable concept and you ought to use it regularly. However, if you dissect "RAII" as an acronym, and if you look (too?) closely at the words making up that acronym, you will realize that the words are not a perfect match for the concept. Who cares?!? The concept is what's important; "RAII" is merely a moniker used as a handle for that concept.
Details: If you dissect the words of the RAII acronym (Resource Acquisition Is Initialization), you will think RAII is about acquiring resources during initialization. However the power of RAII comes not from tying acquisition to initialization, but from tying reclamation to destruction. A more precise acronym might be RRID (Resource Reclamation Is Destruction), but since so many people already understand RAII, using it properly is far more important than complaining about the term. RAII is a moniker for an idea; its precision as an acronym is secondary.
So treat the word "FAQ" as a moniker that already has a well established, well known meaning. A word is defined by its usage.
[ 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 Mar 1, 2006