Home » Blog » Categories »

Quick Q: Can recompiling C++98 code as modern C++ get you performance for free? -- StackOverflow

By Blog Staff | Dec 30, 2014 10:42 AM | Tags: None

Quick A: Yup.

Just before Christmas on StackOverflow:

Can modern C++ get you performance for free?

It is sometimes claimed that C++11/14 can get you a performance boost even when merely compiling C++98 code. The justification is usually along the lines of move semantics, as in some cases the rvalue constructors are automatically generated or now part of the STL. Now I'm wondering whether these cases were previously actually already handled by RVO or similar compiler optimizations.

My question then is if you could give me an actual example of a piece of C++98 code that, without modification, runs faster using a compiler supporting the new language features. I do understand that a standard conforming compiler is not required to do the copy elision and just by that reason move semantics might bring about speed, but I'd like to see a less pathological case, if you will.

EDIT: Just to be clear, I am not asking whether new compilers are faster than old compilers, but rather if there is code whereby adding -std=c++14 to my compiler flags it would run faster (avoid copies, but if you can come up with anything else besides move semantics, I'd be interested, too)

Two fundamental implementations for one conceptual task

By Mark | Dec 30, 2014 09:18 AM | Tags: intermediate

From the Modern Maintainable Code blog:

Two fundamental implementations for one conceptual task

by Mark Isaacson

Summary:

This is the second article of a series on code reuse. This article provides a discussion of how to approach the problem of having multiple implementations of a single idea and how to programmatically select between them based on patterns in the type information of the parameters.

Out in the real world, functions like use the same techniques discussed to leverage std::memcpy internally when it's safe to do so.

<span 1;"="">You can find the previous article of the series here, and the prelude to the next, which looks at solving the same problem for structs instead of functions, here.

Five Popular Myths about C++ -- Bjarne Stroustrup

By Blog Staff | Dec 29, 2014 11:39 AM | Tags: None

Earlier this month, Bjarne Stroustrup posted his new "Five Popular Myths about C++" paper here on isocpp.org in three parts: part 1, part 2, and part 3.

He has now posted the complete paper on his publications page, including typo fixes and some additional comments at the end.

Five Popular Myths about C++

by Bjarne Stroustrup

From the article:

Here, I will explore, and debunk, five popular myths about C++:

  1. “To understand C++, you must first learn C”
  2. “C++ is an Object-Oriented Language”
  3. “For reliable software, you need Garbage Collection”
  4. “For efficiency, you must write low-level code”
  5. “C++ is for large, complicated, programs only”

If you believe in any of these myths, or have colleagues who perpetuate them, this short article is for you...

...

Postscript

The 10 sections of this article was posted on isocpp.org in three installments and reposted widely. It attracted a quite varied set of comments. I have now fixed a few typos that were reported. Thanks.

This postscript is my observations on some of the comments posted.

The comments prove – yet again – that the “Myths” paper was needed. People keep repeating the old hairy rationalizations. Unfortunately, many programmers don’t read long papers and dismiss short ones for being incomplete. The unwillingness of many programmers to read a long paper was the reason I released this paper in three separate parts.

This paper is not a research paper carefully outlining every alternative and carefully documenting every detail. I said that right up front:

Each myth requires a long paper or even a book to completely debunk, but my aim here is simply to raise the issues and to briefly state my reasons.

However, many seems to confuse the examples used to illustrate a point with the point itself. Many tried to “debunk the debunking” by changing examples, by changing the constraints on the examples, or by deeming the examples trivial. The examples are small – they have to be to fit into a short paper – but they are not unrepresentative of code found as part of real-world programs.

Many commenters quickly did a shift from the C++11/C++14 that I base my arguments on to some older version. C++14 is not the C++ of the 1980s. It is not what most people were first taught. It is not the C++ that people is presented with in most beginning C++ courses today. It is not what most people see when they look at a large code base. I want to change that. Not being able to do some example that I present in an antique version of C++ or with an outdated compiler is unfortunate, but better versions of the major compiler ship (typically for free) today. I showed no examples of “bleeding edge” code.

The problem of code in older styles is one that every successful programming language must face, so please don’t judge C++ exclusively based on 20-year-old techniques and 10-year old compilers. Look at modern C++ and find ways of getting it into use – many has already. You almost certainly used a program today that was written using C++11. There are C++11 in many steps of the chain between the computer on which I write this and the computer on which you read it.

Quite a few comments were along the lines of “Language X has a feature that does exactly that” and “Library Y in language X does exactly that.” Obviously, if you have a language that provides a simpler solution to the best you can do in C++, with acceptable performance, portability, and tool-chain constraints for what you want to do, use it. However, no language and library is perfect for everything and everybody.

I present examples of general problems and general techniques. Matching a single example in some way is not necessarily significant. My points are general and the examples only simple illustrations. Given a sufficiently good library, just about any programming task can be simple and pleasant. Given a sufficiently constrained task, we can always design a specialized language to be more elegant than a general-purpose one. For example, the asio library I used in §6.1 is a flexible, efficient, general-purpose networking library. For any one task, I could wrap it in a far simpler function (or small set of functions) to make that task significantly more convenient. The code I showed would then be the implementation. My key point in §6.2 is that the C++ library development community could do many programmers a favor by spending a little more tome making simple things simple. For example 99% of the time I prefer sort(v) to sort(v.begin(),v.end()).

Performance

My comments about performance caused quite a stir in places. Many people tried to dismiss them with arguments or mere counter-assertions. I don’t accept performance arguments unsupported by measurements. My comments have been validated by real performance measures in many contexts over years. Many can be found in the literature. My main performance points hold over a wide range of similar examples and scale.

Please note that I assume a modern, standards-conforming C++ implementation. For example, when I talk about the performance of the short-string optimization, I don’t mean a pre-C++11 standard library without that optimization. Also, I take no notice of comments to the effect that C++ facilities such as std::sort() or std::string are slow if you don’t use an optimizer – of course they are, but talking about performance of unoptimized code is silly. If you use GCC or Clang use –O2; for Microsoft, use release mode.

C

I know C and its standard library pretty well. I wrote considerable amounts of C before many of today’s students were even born and contributed significantly to the C language: function prototypes, const, inline, declarations in for-statement, declarations as statements, and more came from my work. I have followed its development and the evolution programming styles in C.

Yes, the C versions of compose() fails to check malloc()’s return value. I did ask if you thought I got it right. I did not present production-quality code, and I knew that. Failing to check results is a major source of errors, so my “mistake” failing to check the result of malloc() was deliberate illustrates a real problem. As in this case, exceptions can often help.

Yes, you could write the C version of compose() differently using less well known standard-library functions, and yes, you can avoid the use of free store if you let the caller supply a buffer allocated on the stack and let the caller deal with the problem of string arguments that would overflow the buffer. However, such alternatives completely miss the point: it is harder to write such code than the C++ version, and far harder to get it right. Novices get the C++ version right the first time, but not any of the C versions, especially not the C versions that rely on standard-library function not commonly taught to novices.

C++ use

C++ has been used for demanding embedded systems and critical systems for years, examples are The Mars Rovers (scene analysis and autonomous operations), The F-35s and F-16s (flight controls), and many, many more: http://www.stroustrup.com/applications.html. And, yes, the Orion space capsule is programmed in C++.

Libraries

Yes, libraries vary in quality and it can be extremely hard to choose from the large selection of libraries beyond the standard. This is a major problem. However, such libraries exist and researching them is often more productive than simply barging ahead and reinventing yet-another wheel.

Unfortunately, C++ Libraries are often not designed for interoperability with other libraries.

Unfortunately, there is not a single place to go to look for C++ Libraries.

Teaching

I have observed students being taught by the “C first” approach for many years and seen the programs written by such students for decades. I have taught C++ as the first programming language to thousands of students over several years. My claims about the teachability of C++ are based on significant experience, rather than introspection.

C++ is easier to teach to beginners than C because of a better type system and more notational support. There are also fewer tricks and workarounds to learn. Just imagine how you would teach the styles of programming you use in C using C++; C++’s support for those is better.

I would never dream of giving a beginner’s C++ course that

  • didn’t include a thorough grounding in memory management, pointers, etc.
  • didn’t give the students a look at “plain C”’ and some idea of how to use it
  • didn’t present a rationale for the major features
  • tried to teach all of C++ and every C++ technique

Similarly, good C teachers do not try to teach all of C and all C techniques to beginners.

http://www.stroustrup.com/programming.html is my answer to the question “How would you teach C++ to beginners?” It works.

For a rather old paper comparing aspects of teachability of C and C++, see B. Stroustrup: Learning Standard C++ as a New Language. C/C++ Users Journal. pp 43-54. May 1999 (www.stroustrup.com/papers.html). Today, I could write the C version a bit better and the C++ version quite a bit better. The examples reflect common styles of the time (and were reviewed by expert C and C++ programmers).

C++ today is ISO Standard C++14, rather than what I described 30 years ago or what your teacher may have taught you 20 years ago. Learn C++11/C++14 as supported by current mainstream compilers and get used to it. It is a far better tool than earlier versions of C++. Similarly, C today is ISO Standard C11, rather than K&R C (though I am not sure if the C compilers today are as close to C11 as the C++ compilers are close to C++14).

I am appalled by much that is taught as “good C++.”

C++ is not (and never were meant to be) an “OOP” language. It is a language that supports OOP, other programming techniques, and combinations of such techniques.

If you are an experienced programmer, I recommend A Tour of C++ [12] as a quick overview of modern C++.

A Corollary on Overloading -- Mark Isaacson

By Mark | Dec 24, 2014 08:38 AM | Tags: intermediate

From the Modern Maintainable Code Blog:

A corollary on overloading

by Mark Isaacson

Summary from the article:

1) You can extend or adapt other people's code with overloading.

2) It's easy to accidentally eliminate overloads from overload resolution (the set of overloads the compiler considers when calling a function), especially when doing the above. We'll discuss a simple technique to ensure that you don't leave your users in an unfortunate position by accidentally being too specific.

We'll also discuss a few other things along the way, like one reason why non-member functions are more flexible than member functions. We'll highlight why the modern C++11 guideline: 'prefer using the non-member std::begin, std::end, and std::swap functions' exists and why things like non-member std::size are in our near future.

C++ Portable Components Release 1.6.0

By Alex Fabijanic | Dec 24, 2014 08:36 AM | Tags: None

POCO 1.6.0 is now available:

POCO Release 1.6.0 is out

by POCO Team

This release is the culmination of the work done on GitHub over the last two years, including five development releases. It includes major new features from new contributors, like the JSON and MongoDB libraries, much improved Data library, CMake support, as well as numerous other new features and fixes. A big Thank You to everyone who contributed to this release.

What’s New in C++11/C++14? -- KDAB

By don_tait | Dec 23, 2014 10:41 AM | Tags: None

C++11/C++14 will become more and more important in the C++ ecosystem, eventually becoming the most prevalent versions used. Every professional developer should invest in learning the new language version and try introducing its benefits into projects. And for good reasons: C++11/C++14 bring a large range of new features that make development safer, faster, easier and more fun. Once you have tried features like lambda functions, range-based for loops, the auto keyword and the new initialization syntax, you won’t want to go back. In addition to that, many more advanced features like variadic templates, rvalue reference and of course the new standard library additions like multithreading classes, smart pointers, regular expressions and new containers and algorithms complete the picture.

The topics of this course include both the language changes and the standard library changes introduced in C++11, as well as the changes from C++14. Since not every developer has a C++14-capable compiler yet, features only available in C++14 are clearly marked as such in the material. See the table of contents to see the detailed list.

Our full training lasts for three days and covers a wide range of topics, it goes in-depth and provides time to show C++11 examples as well as allowing participants to go hands-on and trying out C++11 themselves in exercise projects.

See the course description for more details about the content.

Embedding Lua into C++ -- Richard Griffiths

By miltonm | Dec 23, 2014 10:38 AM | Tags: None

In case you missed it, this article talks about embedding Lua as a scripting layer in a C++ game:

Mod Support #2 – Embedding Lua into C++   

by Richard Griffiths

From the article:

Lua is the scripting language we decided to integrate into our game’s scripting layer for code logic control. The aim is for the scripting layer to control all gameplay logic while the core, C++, layer will control generic non-gameplay game logic and time critical algorithms.

 

Five Popular Myths about C++, Part 3

By Bjarne Stroustrup | Dec 22, 2014 09:50 AM | Tags: None

myth.png[For your winter reading pleasure, we're pleased to present this three-part series of new material by Bjarne Stroustrup. Part one is here, part two is here. Today we complete the series just in time for the holidays. Enjoy. -- Ed.]

 

Five Popular Myths about C++ (Part 3)

by Bjarne Stroustrup

Morgan Stanley, Columbia University, Texas A&M University

 

1. Introduction (repeated from Part 1)

In this three-part series, I will explore, and debunk, five popular myths about C++:

  1. "To understand C++, you must first learn C"
  2. "C++ is an Object-Oriented Language"
  3. "For reliable software, you need Garbage Collection"
  4. "For efficiency, you must write low-level code"
  5. "C++ is for large, complicated, programs only"

If you believe in any of these myths, or have colleagues who perpetuate them, this short article is for you. Several of these myths have been true for someone, for some task, at some time. However, with today’s C++, using widely available up-to date ISO C++ 2011 compilers, and tools, they are mere myths.

I deem these myths “popular” because I hear them often. Occasionally, they are supported by reasons, but more often they are simply stated as obvious, needing no support. Sometimes, they are used to dismiss C++ from consideration for some use.

Each myth requires a long paper or even a book to completely debunk, but my aim here is simply to raise the issues and to briefly state my reasons.

The first three myths were addressed in my first two installments.

5. Myth 4: "For efficiency, you must write low-level code"

Many people seem to believe that efficient code must be low level. Some even seem to believe that low-level code is inherently efficient (“If it’s that ugly, it must be fast! Someone must have spent a lot of time and ingenuity to write that!”). You can, of course, write efficient code using low-level facilities only, and some code has to be low-level to deal directly with machine resources. However, do measure to see if your efforts were worthwhile; modern C++ compilers are very effective and modern machine architectures are very tricky. If needed, such low-level code is typically best hidden behind an interface designed to allow more convenient use. Often, hiding the low level code behind a higher-level interface also enables better optimizations (e.g., by insulating the low-level code from “insane” uses). Where efficiency matters, first try to achieve it by expressing the desired solution at a high level, don’t dash for bits and pointers.

5.1 C’s qsort()

Consider a simple example. If you want to sort a set of floating-point numbers in decreasing order, you could write a piece of code to do so. However, unless you have extreme requirements (e.g., have more numbers than would fit in memory), doing so would be most naïve. For decades, we have had library sort algorithms with acceptable performance characteristics. My least favorite is the ISO standard C library qsort():

int greater(const void* p, const void* q)  // three-way compare
{
  double x = *(double*)p;  // get the double value stored at the address p
  double y = *(double*)q;
  if (x>y) return 1;
  if (x<y) return -1;
  return 0;
}

void do_my_sort(double* p, unsigned int n)
{
  qsort(p,n,sizeof(*p),greater);
}

int main()
{
  double a[500000];
  // ... fill a ...
  do_my_sort(a,sizeof(a)/sizeof(*a));  // pass pointer and number of elements
  // ...
}

If you are not a C programmer or if you have not used qsort recently, this may require some explanation; qsort takes four arguments

  • A pointer to a sequence of bytes
  • The number of elements
  • The size of an element stored in those bytes
  • A function comparing two elements passed as pointers to their first bytes

Note that this interface throws away information. We are not really sorting bytes. We are sorting doubles, but qsort doesn’t know that so that we have to supply information about how to compare doubles and the number of bytes used to hold a double. Of course, the compiler already knows such information perfectly well. However, qsort’s low-level interface prevents the compiler from taking advantage of type information. Having to state simple information explicitly is also an opportunity for errors. Did I swap qsort()’s two integer arguments? If I did, the compiler wouldn’t notice. Did my compare() follow the conventions for a C three-way compare?

If you look at an industrial strength implementation of qsort (please do), you will notice that it works hard to compensate for the lack of information. For example, swapping elements expressed as a number of bytes takes work to do as efficiently as a swap of a pair of doubles. The expensive indirect calls to the comparison function can only be eliminated if the compiler does constant propagation for pointers to functions.

5.2 C++’s sort()

Compare qsort() to its C++ equivalent, sort():

void do_my_sort(vector<double>& v)
{
  sort(v,[](double x, double y) { return x>y; });  // sort v in decreasing order
}

int main()
{
  vector<double> vd;
  // ... fill vd ...
  do_my_sort(v);
  // ...
}

Less explanation is needed here. A vector knows its size, so we don’t have to explicitly pass the number of elements. We never “lose” the type of elements, so we don’t have to deal with element sizes. By default, sort() sorts in increasing order, so I have to specify the comparison criteria, just as I did for qsort(). Here, I passed it as a lambda expression comparing two doubles using >. As it happens, that lambda is trivially inlined by all C++ compilers I know of, so the comparison really becomes just a greater-than machine operation; there is no (inefficient) indirect function call.

I used a container version of sort() to avoid being explicit about the iterators. That is, to avoid having to write:

std::sort(v.begin(),v.end(),[](double x, double y) { return x>y; });

I could go further and use a C++14 comparison object:

sort(v,greater<>()); // sort v in decreasing order

Which version is faster? You can compile the qsort version as C or C++ without any performance difference, so this is really a comparison of programming styles, rather than of languages. The library implementations seem always to use the same algorithm for sort and qsort, so it is a comparison of programming styles, rather than of different algorithms. Different compilers and library implementations give different results, of course, but for each implementation we have a reasonable reflection of the effects of different levels of abstraction.

I recently ran the examples and found the sort() version 2.5 times  faster than the qsort() version. Your mileage will vary from compiler to compiler and from machine to machine, but I have never seen qsort beat sort. I have seen sort run 10 times faster than qsort. How come? The C++ standard-library sort is clearly at a higher level than qsort as well as more general and flexible. It is type safe and parameterized over the storage type, element type, and sorting criteria. There isn’t a pointer, cast, size, or a byte in sight. The C++ standard library STL, of which sort is a part, tries very hard not to throw away information. This makes for excellent inlining and good optimizations.

Generality and high-level code can beat low-level code. It doesn’t always, of course, but the sort/qsort comparison is not an isolated example. Always start out with a higher-level, precise, and type safe version of the solution. Optimize (only) if needed.

6. Myth 5: "C++ is for large, complicated, programs only"

C++ is a big language. The size of its definition is very similar to those of C# and Java. But that does not imply that you have to know every detail to use it or use every feature directly in every program. Consider an example using only foundational components from the standard library:

set<string> get_addresses(istream& is)
{
  set<string> addr;
  regex pat { R"((\w+([.-]\w+)*)@(\w+([.-]\w+)*))"}; // email address pattern
  smatch m;
  for (string s; getline(is,s); )                    // read a line
    if (regex_search(s, m, pat))                     // look for the pattern
      addr.insert(m[0]);                             // save address in set
  return addr;
}

I assume you know regular expressions. If not, now may be a good time to read up on them. Note that I rely on move semantics to simply and efficiently return a potentially large set of strings. All standard-library containers provide move constructors, so there is no need to mess around with new.

For this to work, I need to include the appropriate standard library components:

#include<string>
#include<set>
#include<iostream>
#include<sstream>
#include<regex>
using namespace std;

Let’s test it:

istringstream test {  // a stream initialized to a sting containing some addresses
  "asasasa\n"
  "[email protected]\n"
  "[email protected]$aaa\n"
  "[email protected] aaa\n"
  "asdf bs.ms@x\n"
  "$$bs.ms@x$$goo\n"
  "cft [email protected]@yy asas"
  "qwert\n"
};

int main()
{
  auto addr = get_addresses(test);  // get the email addresses
  for (auto& s : addr)              // write out the addresses
    cout << s << '\n';
}

This is just an example. It is easy to modify get_addresses() to take the regex pattern as an argument, so that it could find URLs or whatever. It is easy to modify get_addresses() to recognize more than one occurrence of a pattern in a line. After all, C++ is designed for flexibility and generality, but not every program has to be a complete library or application framework. However, the point here is that the task of extracting email addresses from a stream is simply expressed and easily tested.

6.1 Libraries

In any language, writing a program using only the built-in language features (such as if, for, and +) is quite tedious. Conversely, given suitable libraries (such as graphics, route planning, and database) just about any task can be accomplished with a reasonable amount of effort.

The ISO C++ standard library is relatively small (compared to commercial libraries), but there are plenty of open-source and commercial libraries “out there.” For example, using (open source or proprietary) libraries, such as Boost [3], POCO [2], AMP [4], TBB [5], Cinder [6], vxWidgets [7], and CGAL [8], many common and more-specialized tasks become simple. As an example, let’s modify the program above to read URLs from a web page. First, we generalize get_addresses() to find any string that matches a pattern:

set<string> get_strings(istream& is, regex pat)
{
  set<string> res;
  smatch m;
  for (string s; getline(is,s); )  // read a line
  if (regex_search(s, m, pat))
    res.insert(m[0]);              // save match in set
  return res;
}

That is just a simplification. Next, we have to figure out how to go out onto the Web to read a file. Boost has a library, asio, for communicating over the Web:

#include “boost/asio.hpp” // get boost.asio

Talking to a web server is a bit involved:

int main()
try {
  string server = "www.stroustrup.com";
  boost::asio::ip::tcp::iostream s {server,"http"};  // make a connection
  connect_to_file(s,server,"C++.html");    // check and open file

  regex pat {R"((http://)?www([./#\+-]\w*)+)"}; // URL
  for (auto x : get_strings(s,pat))    // look for URLs
    cout << x << '\n';
}
catch (std::exception& e) {
  std::cout << "Exception: " << e.what() << "\n";
  return 1;
}

Looking in www.stroustrup.com’s file C++.html, this gave:

http://www-h.eng.cam.ac.uk/help/tpl/languages/C++.html
http://www.accu.org
http://www.artima.co/cppsource
http://www.boost.org
...

I used a set, so the URLs are printed in lexicographical order.

I sneakily, but not altogether unrealistically, “hid” the checking and HTTP connection management in a function (connect_to_file()):

void connect_to_file(iostream& s, const string& server, const string& file)
  // open a connection to server and open an attach file to s
  // skip headers
{
  if (!s)
    throw runtime_error{"can't connect\n"};

  // Request to read the file from the server:
  s << "GET " << "http://"+server+"/"+file << " HTTP/1.0\r\n";
  s << "Host: " << server << "\r\n";
  s << "Accept: */*\r\n";
  s << "Connection: close\r\n\r\n";

  // Check that the response is OK:
  string http_version;
  unsigned int status_code;
  s >> http_version >> status_code;

  string status_message;
  getline(s,status_message);
  if (!s || http_version.substr(0, 5) != "HTTP/")
    throw runtime_error{ "Invalid response\n" };

  if (status_code!=200)
    throw runtime_error{ "Response returned with status code" };

  // Discard the response headers, which are terminated by a blank line:
  string header;
  while (getline(s,header) && header!="\r")
    ;
}

As is most common, I did not start from scratch. The HTTP connection management was mostly copied from Christopher Kohlhoff’s asio documentation [9].

6.2 Hello, World!

C++ is a compiled language designed with the primary aim of delivering good, maintainable code where performance and reliability matters (e.g., infrastructure [10]). It is not meant to directly compete with interpreted or minimally-compiled “scripting” languages for really tiny programs. Indeed, such languages (e.g. JavaScript) – and others (e.g., Java) – are often implemented in C++. However, there are many useful C++ programs that are just a few dozen or a few hundred lines long.

The C++ library writers could help here. Instead of (just) focusing on the clever and advanced parts of a library, provide easy-to-try “Hello, World” examples. Have a trivial-to-install minimal version of the library and have a max-one-page “Hello, World!” example of what the library can do. We are all novices at some time or other. Incidentally, my version of “Hello, World!” for C++ is:

#include<iostream>

int main()
{
  std::cout << "Hello, World\n";
}

I find longer and more complicated versions less than amusing when used to illustrate ISO C++ and its standard library.

7. The Many Uses of Myths

Myths sometimes have a basis in reality. For each of these myths there have been times and situations where someone could reasonably believe them based on evidence. For today, I consider them flat-out wrong, simple misunderstandings, however honestly acquired. One problem is that myths always serve a purpose – or they would have died out. These five myths have served and serve in a variety of roles:

  • They can offer comfort: No change is needed; no reevaluation of assumptions is needed. What is familiar feels good. Change can be unsettling, so it would be nice if the new was not viable.
  • They can save time getting started with a new project: If you (think you) know what C++ is, you don’t have to spend time learning something new. You don’t have to experiment with new techniques. You don’t have to measure for potential performance snags. You don’t have to train new programmers.
  • They can save you from having to learn C++: If those myths were true, why on earth would you want to spend time learning C++?
  • They can help promote alternative languages and techniques: If those myths were true, alternatives are obviously necessary.

But these myths are not true, so intellectually honest promotion of status quo, alternatives to C++, or avoidance of modern C++ programming styles cannot rely on them. Cruising along with an older view of C++ (with familiar language subsets and techniques) may be comfortable, but the state of software is such that change is necessary. We can do much better than with C, “C with Classes”, C++98, etc.

Sticking to the old-and-true is not cost free. Maintenance cost is often higher than for more modern code. Older compilers and tool chains deliver less performance and worse analysis than modern tools relying on more structured modern code. Good programmers often choose not to work on “antique” code.

Modern C++ (C++11, C++14) and the programming techniques it supports are different and far better than “common, popular myths” would indicate.

If you believe one of these myths, don’t just take my word for it being false. Try it. Test it. Measure “the old way” and the alternatives for some problem you care about. Try to get a real hold on the time needed to learn the new facilities and techniques, the time to write code the new way, the runtime of the modern code. Don’t forget to compare the likely maintenance cost to the cost of sticking with “the old way.” The only perfect debunking of a myth is to present evidence. Here, I have presented only examples and arguments.

And no, this is not an argument that C++ is perfect. C++ is not perfect; it is not the best language for everything and for everybody. Neither is any other language. Take C++ for what it is, rather than what it was 20 years ago or what someone promoting an alternative claims it to be. To make a rational choice, get some solid information and -- as far as time allows -- try for yourself to see how current C++ works for the kind of problems you face.

8. Summary

Don’t believe “common knowledge” about C++ or its use without evidence. This article takes on five frequently expressed opinions about C++ and argues that they are “mere myths:”

  1. "To understand C++, you must first learn C"
  2. "C++ is an Object-Oriented Language"
  3. "For reliable software, you need Garbage Collection"
  4. "For efficiency, you must write low-level code"
  5. "C++ is for large, complicated, programs only"

They do harm.

9. Feedback

Not convinced? Tell me why. What other myths have you encountered? Why are they myths rather than valid experiences? What evidence do you have that might debunk a myth?

10. References

1. ISO/IEC 14882:2011 Programming Language C++

2. POCO libraries: http://pocoproject.org/

3. Boost libraries: http://www.boost.org/

4. AMP: C++ Accelerated Massive Parallelism. http://msdn.microsoft.com/en-us/library/hh265137.aspx

5. TBB: Intel Threading Building Blocks. www.threadingbuildingblocks.org/

6. Cinder: A library for professional-quality creative coding. http://libcinder.org/

7. vxWidgets: A Cross-Platform GUI Library. www.wxwidgets.org

8. Cgal - Computational Geometry Algorithms Library. www.cgal.org

9. Christopher Kohlhoff : Boost.Asio documentation. http://www.boost.org/doc/libs/1_55_0/doc/html/boost_asio.html

10. B. Stroustrup: Software Development for Infrastructure. Computer, vol. 45, no. 1, pp. 47-58, Jan. 2012, doi:10.1109/MC.2011.353.

11. Bjarne Stroustrup: The C++ Programming Language (4th Edition). Addison-Wesley. ISBN 978-0321563842. May 2013.

12. Bjarne Stroustrup: A Tour of C++. Addison Wesley. ISBN 978-0321958310. September 2013.

13. B. Stroustrup: Programming: Principles and Practice using C++ (2nd edition). Addison-Wesley. ISBN 978-0321992789. May 2014.