• A lot of C programmers fear C++ for the same reason that VB programmers fear C: If you think pointers are "useless" or "confusing", the language is not the one with the problem. The same holds true for templates, multiple inheritance, encapsulation, etc. Somebody who's driven a horse and buggy all his life would consider a steering wheel equally "useless".

  • Those who have used the static keyword in C have used encapsulation. Encapsulation is good.

  • 99.9% of people who call C++ "inefficient" have no idea what they mean by it. The other 0.1% are sometimes mistaken, depending on what feature they're referring to. Sometimes they're dead right, though.

  • In fact, people who hate C++ usually seem to be either in the early stages of learning it, or in the late stages of avoiding learning it. It's hard to learn; C++ is subtle and quick to anger, you might say. But lots of good things (e.g. C) cost something to get in the door. It's painful for me to go back to C now. There's a "paradigm shift": If you're thinking in structured programming terms, OOP features will naturally seem useless, just as structured programming features seemed useless to the old guard during the GOTO wars twenty-five years ago. Mastering C++ is a matter of learning why the features are there as much as learning the syntax. The syntax is the easy part.

    Some people like OOP, but they don't understand relatively low level languages; others like relatively low level languages, but they don't understand OOP. Well, there you go: C++ is both.

C++ attempts to do anything you can imagine. You can't please everyone all the time, but you can please some people all the time or everyone some of the time. Many languages out there specialize on one task. PHP makes web programming easy for anyone, for example. C++, if you choose to learn it, is the right tool for nearly every job. It just has so many features that there's almost nothing it can't do.

This is more or less the purposeful direction of the ISO 14882 standards committee. If there is something that could possibly be practical in C++ - say, a flexible functional language for implementing metacompilation algorithms - the committee will recognize it as an important potential use. Through the BOOST header library, there is an established path from experimentation to standardization. Furthermore, the standards committee holds regular, open meetings where technical progress actually occurs.

Why is a jack-of-all-trades so useful as to attract such research effort, not to mention the energy it takes adopters to learn such advanced (but unfriendly) features as MPL?

For example, any random programming interface in C or C++ can be mapped to using C++ templates. Say you have several unfortunately redundant interfaces existing in your project, and you can't really eliminate or unify them. C will let you write a map from several interfaces to one engine, which might help performance. But confusion is as much of a problem as performance, if not more! It's really nice to have only a single interface for a particular job. First, encapsulate the relevant state information and procedural idioms into a C++ template. Then, use template specialization to implement glue from the common interface to each of the redundant components. When you want to write some new code for the crappy interfaces, call the template and tell it to adapt appropriately for the crap interface you'd otherwise be using. You can use a single interface for all your existing messy, heterogeneous code!

Bonuses on the above include friendly type-error messages when you get confused about which interface you're supposed to be using, and instant translation between the interfaces if you implement a copy constructor for the template.

In conclusion, C++ gains unique abilities from being a copycat. Software fires result from the language not supporting desired constructs, or for myriad other reasons. C++ is a fire hose.

A'course, in the wrong hands, a fire hose can be very destructive, too.

Log in or registerto write something here or to contact authors.