C++ Turns 30 – Looking Forward to the Future

[Bjarne Stroustrup] introduced C++ to the world on Monday 14th October 1985 at the ACM annual conference on “The Range of Computing”. On its 30th anniversary [Bjarne] reviewed the history, his experience, and his thoughts on the future of the language in an interview. Also on that day the first edition of his book, “The C++ Programming Language” was released. It’s now available in a 4th edition. The title differed only in the “++” from the classic C book by [Kernighan] and [Ritchie] that graced the desktops of a multitude of C programmers.

The first versic++ bjarneons of C++ were compiled with CFront, a compiler that generated C code which was then compiled as normal. Around the 1990s, it’s unclear when, numerous native compilers became available, notably for PCs, which lead to explosive growth from 400,000 users to an estimated 4.4 million today.

 

One of the frustrations [Stroustrup] expresses is how C++ is viewed by developers,

… a problem that has plagued C++ forever: Poor teaching and poor understanding of C++ even among its practitioners. There has always been a tendency to describe C++ as some odd variant of something else.

Soon the standards committee is meeting to discuss C++17 in Hawaii. Fair winds and bright skies look to be in the future of C++.

37 thoughts on “C++ Turns 30 – Looking Forward to the Future

  1. Burn it with fire and go over to golang… :-) – but I’m not sure that I’m actually joking… I’ve never liked object oriented programming. Maybe that is because I started out with assembly and then moved on to C.

    1. I stared out with C, and moved on to C++ shortly after that. Once the whole OOP thing clicks, it’s much easier to deal with.

      Of course the ability to link with Python (via python-config), Java (via JNI, pretty ugly), C (extern “C”), etc. is also nice.

    2. I think that the intentions of OO in C++ are quite different than what people thinks. I have seen people writing Java in C++, trying to fit everything in a class. But if you look at the stl, objects mostly encapsulate resources (vector, array, string, smart pointers…), which is something objects do well, and provides a clean way of ensuring you don’t leak anything. The other major use of classes/structs in stl is to take advantage of templates, which properly used are a great boost for the language. If your problem in question does not match OO principles you can write clean, scoped, modules of functions using separated files and namespaces, and your code will be clean, clear, reusable and beautifully written in C++.

      The thing I don’t like in C++ is that has too many stuff from the old C and the developing C++, and some of that stuff still cannot be removed without leaving a hole; includes are not the best thing, macros are still around, and ugly hacks are sometimes needed with templates. If a new language had the same principles I see in the design of stl but dropped all the ugliness remaining in C++ i’d switch to it and never go back.

    3. C++ is the most expressive programming language out there, and thus the most complicated one to learn. It has everything; templates, classes, generics, functional programming, OOP e.t.c. This makes it excellent at modeling and abstraction but it can be quite hard to learn to program in C++ properly.
      I peronally enjoy programming in C++, especially when using it within the context of the Qt Framework.

      Golang on the other hand, while it is a great language in its own right, with great growth potential….it is not as flexible nor as expressive as C++ but it is really not meant to be…That’s the whole point…it’s supposed to be an easy language to learn and use and possess a minimum number of features required to make it a success. Golang’s major weakness is its lack of libraries (especially native libs) out there. But that should change quickly. Golang is still slightly older than 5 years.

      BTW golang does OOP. It just does it without classes

    1. Guess you never made a program larger then a shoe-box. Cause every program I’ve seen larger then a man year of development is ether OO, or a spaghetti code mess.
      I’ve seen C programmers really express hate for C++, and then you look at their code and they are just replicating C++ classes with plain C code. Doing all the work themselves instead of letting the compiler do it.

    2. Your unfounded comment about socialism aside, OOP lends itself to express solutions to certain domains quite naturally. To name at least one example; interaction of stateful entities as you would find in game design.

        1. Only if you have a funky definition of socialism.
          Socialism works well in a large part of the world and even in US there are socialistic tendencies that improves the lives of the majority. It will not be _called_ socialism there though…

  2. I read some comments on the net about how one needs to really learn how to program in c++, rather than just “C with classes.” By this, they seem to mean that you should use the features that are unlikely to work in deeply embedded environments, and cause program size bloat on other platforms. (“Use the STL and automatic dynamic memory allocation.”) (I particularly like the “really good example of actual C++” I found that compiled to about 60% bigger than the “bad, C with classes” style program.) Sigh. :-)

    1. Generally the use of standard library features should have a negligible impact on the compiled binary, especially when compiled with the correct compilation flags. I would be interested to see this example you speak of.

      A tangential caveat, you really should try an avoid allocating dynamic memory on embedded systems.

    2. There are two things I consider wrong in that comment. First, the features of the language won’t stop working because you are compiling for an embedded system (maybe threads if your environment don’t allow such a thing). The only thing that will make standard features nonfunctional is a nonstandard compiler.
      Second, performance isn’t always in the side of C, sometimes C++ compilers can do optimizations that C compilers do not. As an example, functors can more often be inlined by the compiler than function pointers. In general, if your compiler is a decent C++ compiler (gcc/clang), the code is properly written and compiler optimizations are enabled the performance loss should be minimal or even not a loss but a performance gain.

      1. The “features of the language” can include use of run-time libraries and features that don’t exist for a particular platform (ie STL, as I understand it, makes heavy use of dynamically-sized containers, requiring significant ram, dynamic allocation, and a fair amount of code. “String” and “New” aren’t even implemented on Arduino (or, not “correctly” anyway.) A good C++ programmer would probably look at avr-g++ and say “no! That is not C++!”
        The example was at http://programmers.stackexchange.com/questions/48401/learning-c-properly-not-c-with-classes
        Here’s their “good” C++ program. It sorts lines from stdin. You can tell it does that, right? (Hmph.)

        class line { 
            std::string data;
        public:
            operator std::string() const { return data; }   
            friend std::istream &operator>>(std::istream &is, line &l) { 
                return std::getline(is, l.data);
            }    
        };
        
        int main() { 
            std::set<std::string> lines((std::istream_iterator<line>(std::cin)), 
                                        std::istream_iterator<line>());    
            std::copy(lines.begin(), lines.end(), 
                      std::ostream_iterator<std::string>(std::cout, "\n"));
            return 0;
        }
        
        1. Actually, yes I can tell what it does. It might have taken me a few minutes longer if you hadn’t provided the hint that it is sorting the lines but I would have gotten it. I’m a little bit bothered by the use of a ‘set’ instead of a ‘multi-set’ since, off the top of my head here, the set is going to eliminate any duplicate lines. A multi-set wouldn’t.

          I am not knocking Java when I say the biggest problem I had with it was learning the libraries. By the time I worked with Java in the early 2000s I had absorbed the C++ libraries through use and study. Trying to get all the Java libraries at one time was trying to drink from a fire hose.

          I can see where learning the C++ to a newcomer would be a challenge.

    3. I started with C++ in ’90s – reading the Borland manuals on vacation in Hawaii just as Iraq invaded Kuwait. Weird how that is associated… Anyway, over the next 5 years I went through 3 distinct changes in my understanding of using C++. I can no longer elaborate each step, unfortunately, but they were definitely there. The first was the comprehension of encapsulation but that was an extension of structured programming data hiding. Another was seeing classes as more than just data and operations welded together. They became more truly abstractions of an entity with behaviors. Cannot remember the third shift. As you point out you can go overboard. You do have to keep in mind your overall system requirements.

    4. @WestfW
      Your post reads like you’ve never worked outside of embedded systems–or maybe like you’re still in college–because you think executable size is the only parameter worth optimizing, or that it correlates reliably with efficiency or speed of execution.

      If you’d worked on a larger app with a team you’d know that sometimes it’s worth sacrificing executable size in favor of maintainability, scalability, modularity, any number of other qualities, or combinations thereof.

      Don’t get me wrong, C++’s features provide a stupendous amount of rope to hang oneself with, but no one’s making anyone use them. Not every project has to take advantage of the template system and preprocessor directives both being turing complete.

      1. Could be. The two-faced-ness bothers me. On the one hand, some C++ programmers are enticing embedded engineers: “use C++; it has features that will improve reliability and productivity without causing bloat!”, and on the other hand there is the “If you’re not using STL and other bloat-inducing features for everything, you’re not really programming in C++.”

  3. Wow, only 4.4 mil estimated users ?

    Not that this does not imply broad acceptance, but in the grand scheme of things, world population, etc. suddenly the ‘tech world’ starts to feel like a tiny island.

    1. Assuming that a major part of the human world has a life under the poverty line and under the fact that we have many human beings on earth that are younger than 15 years and many that are older than 60 years, and understanding that there are many constrcution worker, med. Dr., teachers and Accountants and also a lot of woman in the world that do not work in a profession at all but care for their family…. I find 4.4M rather high.

        1. What portion of internet users are actually using the internet, rather than using a device that relies on the internet? Of those, how many use sites other than facebook, reddit, etc? Of those, how many have the skills to actually write code? How many actually do on a regular basis? How many specifically write C++? Keep in mind that this basically excludes web devs, android/ios devs, huge swaths of the research world, and many other groups.

          Seriously, try plugging in numbers. Think of it as a demographics Drake Equation. A few million doesn’t seem too implausible to me.

      1. The typical C++ hater either hes never written any real program in C++, or has tried to use it as if it were C and thus got frustrated.
        Things gets worse if you add in the false assumption that a simple programming language leads to simpler programs.
        Also C++ is well usable for (especially 32bit) microcontrollers, if you don’t start coding with an already biased attitude that it won’t be efficient.

  4. OOP supporters really need to stop treating whatever the OOP special of the week as the one for all language. The OOP detractors need to stop acting like OOP is some sort of conspiracy. No one has just one utensil in their kitchen, no one should just use one language for everything.

    If I only have a handful of space in a microcontroller, go with ASM. If I want to add a little sophistication and got more space and power, I move up to C. If I’m working at modern PC levels, move up to the appropriate tool for the job. Do I need to chew up gigabytes of raw text? Perl or Python is good. I hate Java but I’ll use it when I’m targeting multiple OSes. C++ is easy to use. C# has its place. Visual Basic works OK RAD. Basic is a good starter for beginners but care should be taken not to trap them. I teach Scratch to very young kids and a six year old girl in my class discovered Alice (which I’m racing to learn to teach her).

    Not asking for the whole peace Earth thing but damn… let’s get back to the real goal here. Killing each other with giant fighting robots.

  5. C++ is a path to solid abstractions, or it is also a path off a cliff. What I like is the old concept that each design decision should be wrapped in a function. A class is a group of tightly-coupled design decisions wrapped in the class.

  6. Sorry, but I’m looking forward for it to have a cardiac arrest and die so someone will give me a language for small micros that’s not so cryptic. I’ve taken classes, experimented and worked my tail off and I just don’t get it. I’m sorry, but I like more English-like languages. When people are proud of their obfuscation, I just can’t use that language. A good working language should be clear, concise and simple for its users. End of my soapbox.
    Harley

  7. ITT: “It doesn’t work for me, so NOBODY should use it!” and “It works for me, so EVERYBODY should use it!”

    Both sides can piss off. Use the right tool for the job. Just because you CAN doesn’t mean it’s the best way.

    1. Exactly. Trying to force object orientation everywhere creates messes like Java, not using object orientation where the model fits creates inflexible code and/or spaghetti. But no model fits all kinds of code.
      Table driven programming can make some tasks compact, fast and easy to read/change. Functional programming works great for a problem suitable for it. Standard structured programming is assumed nowadays but shouldn’t be forgotten. For some problems multi-methods improves productivity greatly while making even complex stuff easy to read.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s