back to article The New C++: Lay down your guns, knives, and clubs

"The world is built on C++," Herb Sutter tells The Reg. Considering he's one of the language's chief stewards, we question his impartiality. But he does have a point. After more than 30 years – depending on whose numbers you swallow (these or these) – C++ remains one of computing's most popular programming languages, favored …

COMMENTS

This topic is closed for new posts.

Page:

  1. Pseu Donyme

    Hmm ...

    Still no standard library / keywords for multithreading / synchronization though ? (Something akin to Java's (Concurrent Pascal's) would have been welcome ... ).

    It seems that the basic idea (by Brinch Hansen, Hoare, ...) from the 1970s of "safe" languages, that is, trading some runtime speed for an easier implementation still fails to catch on :). While waiting for that, libmudflap (BoundsChecker,...) can be used to achieve similar results with C/C++ (for test/development), in practice, catching a bunch of bugs "free". These days many of the actual runtime environments can support these for weeding out bugs, for an embedded system without a MMU and/or the memory to spare one should be able to run (most) of the same code on a workstation for testing purposes (extra work for setting up some kind of a simulation though).

    Originally I owe the above insight to converting a 1990s real-mode x86 (DOS) C (C++) system to 286/16-bit protected mode (DOS extender providing an enviroment like 16-bit protected mode Win 3.x) . As a side effect I ended up with a system where most logical pieces of memory had an individual, HW bounds check at runtime. The amount of bugs this catched was quite phenomenal, and, importantly I was able to set up an exeception dump facility which allowed me to trace a run-time exeception, even one that would happen only every once in a blue moon back to the source line and machine instruction. With the CPU register values it was usually easy enough to figure out what had gone wrong (the typical fix being adding an explicit bounds check to array access: unchecked, these are may crash the system down the line when it is involved with some other section of code entirely ...).

    1. Ken Hagan Gold badge

      Re: Hmm

      "Still no standard library / keywords for multithreading / synchronization though ?"

      I think you'll find there *is* library support and that new keywords aren't necessary.

  2. Anonymous Coward
    FAIL

    Why support concurrency?

    If the language is going to support threading then why not multi-process too. Lets ditch fork() and createProcess() and have some standardised feature set. No? Why not?

    I'll tell you why not - because these are OS specific features and a 1 size fits all approach simply doesn't cut it when you need to get really down and dirty with the OS. I'll be interested to see how they merge the Windows threading model with pthreads - but I suspect a dog will be getting its dinner.

  3. Tom Reg

    C++ - way too complicated

    It's possible to write code in c++ that is completely unreadable by anyone but an expert in the language - some STL code comes to mind. It's also possible to make it readable, but I am not sure that is the norm. I wrote a large program in it 10 years ago and when that was over I swore never again. My experience is that with C++ you spend a lot time on the language and not working on the problem.

  4. Anonymous Coward
    Anonymous Coward

    Yawn

    Will C++0x have a consistent bit-width data types across CPUs? I bet not, given you need a language completely detached from C for that!

    Will C* code and data structures continue to break as new *-endian CPUs come out, like between 8-bit, 16-bit, 32-bit, 64-bit, X-bit CPUs and all that horrid data-type and data structure macro hacking (e.g. for Microsoft and other OS's) because there is no VM to abstract away this native hacking? I bet so!

    Will we continue to see the absurdity of buffer overflows and null pointer bugs because of the inherently unsafe memory model of the C/C++* family of 'bare metal' languages, especially in common C/C++ libraries and OS's? Of course!

    Most of the Microsoft security issues relate to this inherently unsafe memory model, the rest are higher level issues like SQL injection exploits.

    How long before there are fully usable and stable compilers and IDEs for common OS's for C++0x? 5 to 10 years, or never.

    In that time, advances in Java or other higher level languages will have rendered it even more irrelevant, maybe even for OS and driver coding.

    Objective-C is kludge which is only relevant to Apple platforms, thus irrelevant to most application developers. Apple is part of an expensive lifestyle fad and has a limited lifespan, so beware about investing much of your life with them.

    1. Anonymous Coward
      FAIL

      @AC 22:16 GMT

      Of course not.

      Different standard bit widths on different platforms are key for performance - which is what C and C++ are about fundamentally. The standard says that int should be the standard bit width for that platform, and that makes sense because it will be the size all the registers are designed to operate with. This is why C (and to a lesser extent C++) dominate in embedded systems.

      If you want to use types that are fixed across platforms, use int32_t, etc. (in C++0x) or the boost equivalents (before C++0x).

      Many compilers are almost ready to go with C++0x, even before it has finally been standardised. Especially gcc where most of the features have been prototyping for years.

    2. Someone Else Silver badge
      Thumb Down

      @Yawn

      "Will C++0x have a consistent bit-width data types across CPUs? I bet not, given you need a language completely detached from C for that!"

      Say what?

      C99 supports (and has for the last dozen years!) consistent bit width types (int8_t, uint32_t, etc.). I would expect C++ to do the same (are you listening, Herb?)

      You really need to get out more...

    3. Conner_36
      Meh

      "Objective-C is kludge"... really?

      "Objective-C is kludge which is only relevant to Apple platforms, thus irrelevant to most application developers. Apple is part of an expensive lifestyle fad and has a limited lifespan, so beware about investing much of your life with them."

      Them's mighty strong fightin words.

      Just a look by the numbers, ios is more popular than every current game console by the numbers. But being nice I added all of the original numbers to make it a 'fair' fight.

      We have the nintendo brand at 602.42 million since 1974; the sony playstation brand at 369.8 million since 1994; the xbox brand at 79 million consoles sold since 2001; then we have apple's ios brand at 193.62 million since 2007!

      Or nintendo at 16 million per year; sony at 21 million per year; microsoft at 7.9 million per year; apple at 48 million per year.

      So by your logic microsoft shouldn't even be trying with the kinect! They should just shut down their games division because no one likes… um wait exactly how do you judge relevant?

      -----(how I came by my numbers)-----

      xbox at 24 million

      http://web.archive.org/web/20080621155352/http://www.xbox.com/zh-SG/community/news/2006/20060510.htm

      xbox 360 at 55 million

      http://majornelson.com/2011/06/03/a-few-stats-before-we-head-into-e3/

      ps3 at 50 million

      http://www.scei.co.jp/corporate/release/110415_e.html

      ps2 at 150 million (includes sell in)

      http://www.scei.co.jp/corporate/release/110214_e.html

      playstation and ps one at 102 million

      http://www.scei.co.jp/corporate/data/bizdataps_e.html

      psp at 67.8 million

      http://www.scei.co.jp/corporate/release/110228_e.html

      wii at 86.01 million

      http://en.wikipedia.org/wiki/Wii#cite_note-earnings_release_Q4_2010-42

      3ds at 3.61 million

      http://www.nintendo.co.jp/ir/pdf/2011/110425e.pdf

      ds at 146.42 million

      http://www.nintendo.co.jp/ir/pdf/2011/110425e.pdf#page=16

      game cube at 21.7 million

      http://www.webcitation.org/5nXieXX2B

      N64 at 32.9 million

      http://www.webcitation.org/5nXieXX2B

      super nintendo at 49.1 million

      http://www.webcitation.org/5nXieXX2B

      nes at 61.91 million

      http://www.webcitation.org/5nXieXX2B

      entire gameboy line at 200 million

      http://digital.asiaone.com/Digital/News/Story/A1Story20090423-137056.html

      virtual boy at 0.77 million

      http://www.gamepro.com/gamepro/domestic/games/features/111823.shtml

      all iphone versions 108.62 million

      http://en.wikipedia.org/wiki/File:IPhone_sales_per_quarter_simple.svg

      all ipod touch 60 million

      http://thisismynext.com/2011/04/19/apple-sues-samsung-analysis/

      all ipad 25 million

      http://www.sfgate.com/cgi-bin/article.cgi?f=/g/a/2011/06/06/businessinsider-new-expectation-for-ipad-sales-8-million-this-quarter-2011-6.DTL

  5. Anonymous Coward
    Anonymous Coward

    C++ vs other languages

    I love C++, because I can write large, complex applications for some projects but if I want to bring a program up on bare metal I can do it in just a few lines of assembler. You just set your stack, call all your static constructors and that's about it.

    It's a pity because C++ v1.0 only really needed operator overloading, out-of-scope destructor calling, and the class notation. It could lose inheritance, exceptions, RTTI, STL and still be incredibly useful, even as a SIL. I'm guessing that while the C++ standards committee were dotting every I and crossing every T, huge amounts of insecure C code got written. Perhaps if they had just produced a decent string class with everything you need, like CStrings Get/ReleaseBuffer(), Python's startswith() and endwith(), and ability to construct from either unicode or ascii strings like CComBSTR, perhaps a default 1k string buffer, and then copy-on-write system when it overflows, then maybe it would be just too useful to not use and you wouldn't get all these died in the wool C hackers coming up with rather specious arguments against C++. Linus might have used it for his kernel, and a bunch of other developers wouldn't be put off by the 'space-age' features that people seem to like abusing, damaging readability and sometimes even run-time efficiency.

    I know you can get all kinds of clever things with the Boost libraries but that's not really the point. Python, Java and other languages, even if slower seem give you what you need instead of what some academic-types think you want, and that's what I see as the main problem with C++.

    I'm not looking forward to a new C++ compiler. It looks like it'll give me virtually nothing I'll use so I may as well stick with the threading abstractions I'm already using, and compilers that I know and understand for all the major platforms.

    1. Anonymous Coward
      Anonymous Coward

      Quite right

      I think Bjarne might well agree too - I remember a talk of his (sponsored by Microtec, remember them?) entitled "C++ as a better C"; in it he described the usefulness of the C++ features that match v1.0 as you describe it, pretty much.

      template metaprogramming? I get DSL, I *really* do, but ... sigh ... what's wrong with lex and yacc? *really*?

  6. vic 4
    Unhappy

    Copyright violation?

    Eh, is the ISO standard not subject to copyright protection? Has however is hosting that pdf got permission to distribute it for free? I had to fork out about $30 for my copy many years ago.

  7. Martin
    Happy

    Time to ask Verity what she thinks....

    http://www.theregister.co.uk/2009/05/07/verity_stob_cplusplus/

    It would be nice to see an updated version of this.

  8. Vanir

    @Tom Reg

    "My experience is that with C++ you spend a lot time on the language and not working on the problem."

    My experience is that programmers work on the problem and the code at the same time - that's the problem.

    1. Anonymous Coward
      Anonymous Coward

      @vanir

      "My experience is that programmers work on the problem and the code at the same time - that's the problem."

      Sometimes you don't know what the problems will be until you start to write and test the code.

      Sure, you can nail down the low level design and all the potential issues for some noddy 1000

      line project , but its a different story when scaled up to 100,000 lines with a dozen coders.

  9. Field Marshal Von Krakenfart
    Paris Hilton

    Rubbish

    The Tiobe survey is complete ++ungood

    Cobol only marginally more popular than Fortran, cobblers!

    Paris, the only compile-her that can deal suckessfully with dangling pointers

  10. Anonymous Coward
    Holmes

    Remember the reason for C++

    There are a lot of people on this forum bitching about issues with C++, where really they mean issues with C. Things like buffer overruns, NULL pointer problems, etc.

    I invite all those people to stay with their managed languages. The reason C++ is still so hugely popular is simple. It is the only language where you can get raw speed combined with object orientation. It also has the best generics solution of any language. Since the standardisation of templates in 1998, other languages have been playing catch-up. Templates and operator overloading were what persuaded me C++ was the language to use back in 1992, since then the raw speed has kept me there.

    In return for the raw speed there are lots of things you have to think about which you can ignore in other languages. Memory management and raw pointers are the main ones. But you know what, these are the reasons you can get such blazing speed out of C++. To quote Spideman, "With great power comes great responsibility."

    There are a lot of things I'm looking forward to in C++0x. The article concentrated on the memory model, which I think is good because this is one of the things we have all been waiting for. Rvalue references and move constructors are very interesting because they essentially allow you to write even faster code, especially when using a class with overloaded operators. Type inference (the auto keyword) will help to make a lot of template code more readable. It also makes some templatised code possible where it wasn't before. Range based for will make working with the STL more comfortable. There are a bunch of template improvements I'm looking forward to: variadic templates and template aliases are the most obvious.

    My biggest concern is not about security vulnerabilities. It is actually that C++ is getting difficult to learn. When I was a student in the 90s everyone learned C or C++. That was good because difficult concepts like pointers were covered. These days lots of universities teach Java and specifically ignore everything to do with pointers. I don't mind that too much since it means that there is an army of programmers capable of doing routine run of the mill coding. It does mean we are seeing less C++ specialists, and as such high standard C++ programmers are becoming harder to find. What I have started to do is pick out the very best Java or C# programmers, and re-tread them into C++ programmers!

    1. Anonymous Coward
      Devil

      Absolutely

      To quote Spideman, "With great power comes great responsibility."

      A lot of people seem to forget a couple of points.

      There are a lot of C++ 'coders' out there who still rely on the C elements of the language, who'll use raw arrays instead of an STL collection etc.... This is language abuse. Of course it causes problems when you are actually writing code in one language (C) but calling it another C++

      You don't blame the car when a drunk driver has an accident do you?

      For instance there was a famous class in an application developed by an ancient team at a place I worked. This one 'class' was 10 print pages long

      Also you need to use the right tool for the job. When modelling vast, complex real world problems, such as mobile phone networks for example. You don't want to be trying to relate a bunch of raw arrays with each other. A well developed OO data model provides an easy interface for the the higher levels of the application to deal with.

      We redeveloped one such application which although supposedly written in C++ did not make any use of a coherent OO data model possibly because it had to pass this data onto a discrete optimiser. This meant that adding a brand new technology to the network required a massive redevelopment. So to avoid having to do the same thing the next time a new mobile protocol was invented we re-designed.

      By making use of templates, inheritance and polymorphism our data model could be viewed by the higher levels as a mobile phone network, but the actual optimiser only saw it as a collection of discrete numbers with degrees of freedom to be manipulated. Because of this multiple perspective view of the data we were able to negate the need to translate the higher level data to a view the optimiser could understand. This resulted in a 30% speed up which really makes a difference on an optimisation that can several weeks to run. Not something we could have achieved with Java or .net I believe.

      It turned out there were quite a few 'c++' developers in the company who had never used templates and almost never utilised polymorphism or overloading and so found the solution very difficult to understand. We also supplied highly detailed UML diagrams & documentation of the model and there were also a lot of developers who didn't really understand them either.

      The language though did it's job and provided us the tools to produce an efficient, extendable solution to a complex problem. In general It is the level of knowledge of the development community that lets the language down.

      No doubt there will be C++0x programmers coding in C++ (and still probably C) for many years to come.

      1. Anonymous Coward
        Anonymous Coward

        Re: Absolutely

        "There are a lot of C++ 'coders' out there who still rely on the C elements of the language, who'll use raw arrays instead of an STL collection etc.... This is language abuse. Of course it causes problems when you are actually writing code in one language (C) but calling it another C++"

        I actually agree with quite a lot of what you say, but I don't think using C features in C++ is "language abuse". Raw arrays are actually very useful to get access to the blistering speed of the OS. The nice thing about raw arrays is that you can use them just like an STL collection. In fact in C++0x you can even throw a raw array at the range for and it just works.

        Obviously, most people wanting to use an array could get equally good results from an std::vector, but if your data absolutely has to live on the stack for performance reasons then a raw array is fine. Take a look at the implementation of boost.variant for example. Under the hood the storage is a raw char array (with some alignment foo).

    2. Mason Wheeler

      Fact check

      >It is the only language where you can get raw speed combined with object orientation.

      You've obviously never used Delphi. (Which also offers a syntax that mere mortals can understand.)

      >It also has the best generics solution of any language.

      Excuse me? C++ templates have got to be the worst generics solution ever invented. Take a code-generation scheme that, by definition, has to be evaluated to completion by the compiler, and make it Turing-complete? Yes, what a wonderful idea!

  11. ForthIsNotDead
    Thumb Up

    LOVE FORTH? IF HONK THEN

    Forth is still around. Does everything you need, and close to the hardware as you'll get without resorting to assembly.

    1. Anonymous Coward
      Anonymous Coward

      HONK

      wouldn't bring up the first spin of the hw any other way

  12. Yet Another Anonymous coward Silver badge

    There is a world outside Cobol

    ADD TRANSACTION-AMOUNT TO LEDGER-BALANCE works but -

    "ADD THE FLOATING POINT ABSOLUTE OF THE PHASE OF THE INPUT SIGNAL IN RECEIVER 7 OF BLOCK 3 OF RACK 12 TO THE ACCUMULATED SUM OF THE PHASE DIFFERENCE IN THE MAXIMUM ENTROPY FUNCTION UNLESS THE COMPLEX PART OF THE BASELINE IS MORE THAN ..."

    Is probably easier to put in as a formula.

    1. Anonymous Coward
      Anonymous Coward

      I get it, so what you're saying is ...

      Different tools for different jobs! Each taken on their own merits?

      Eureka!

      jake, are you there? are you listening?

      1. jake Silver badge

        @AC21:13 ... Where did I say I didn't use different tools for different jobs?

        I was commenting on real programming, not the likes of "Farmville" ... If the underlying hardware+OS isn't stable, none of your toys, bells & whistles will mean squat.

  13. Anonymous Coward
    FAIL

    "buffer vulnerabilities ... underlying Intel architecture "

    Rubbish. Nothing to do with x86 architecture.

    Give me a processor and an OS that will (1) allow me to write stuff to the heap (or maybe elsewhere) as data (2) allow me to execute that stuff as instructions. I'm all set for a vulnerability.

    There are lots of processor/OS combinations that permit that kind of thing. Common OSes on x86 are some of them but by no means all of them.

    Go back to CompSci 101 and start again.

    Tom Welsh: nice to see you here again. You should pop by more often.

    Mentions of Occam: just goes to show that there's very little in the world of programming that hasn't already been done, and sometimes done well. Communicating Sequential Processes. Pools and channels. What else could possibly be necessary?

  14. Robinson

    Yea, ok....

    And you people who say the world isn't built on C++, but is instead built on Java, Python, Cobol, or whatever. which language do you think was used to create all of those? C/C++ is the foundation stone of pretty much everything IT, even your mobile device.

    1. Oninoshiko
      FAIL

      Hello Mr. Wells,

      Cobol first appeared in 1959, C didn't appear until 1973.

      So either you have access to a time machine, or have no idea about the history of computing.

    2. Anonymous Coward
      Facepalm

      also ...

      Robinson: you also appear not to have heard of self-booting compilers. Its possible to build a compiler for any language in the language its intended to compile. Indeed a complete language should be able to build itself. OS's are like that too.

      But I'm guessing compiler theory and machine code isn't probably your strong suit.

      Here's a quick backgrounder: http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29

      1. Robinson
        Facepalm

        Chicken and Egg

        "you also appear not to have heard of self-booting compilers."

        You need to read the section entitled, "the chicken and egg problem".

        1. h4rm0ny

          Re; Chicken and Egg

          Chicken and Egg may sound like an insoluable problem in the abstract, and yet the world contains both chickens and eggs somehow. It is possible to write a compiler for a language in the language itself. Well maybe not in Python, but you can in C.

          1. Anonymous Coward
            Anonymous Coward

            "Chicken and Egg"

            The reality is that you have to cross-compile or have an equivalent means of generating the 'first' object code such as running the compiler source on an interpreter to compile itself. How else ?

            1. Anonymous Coward
              Anonymous Coward

              The equivalent means being ...

              To have an assembler, coupled with a suitable parser and rule table for your chosen syntax, which then emits many machine instructions per statement. Thus, surely, any programming language can concocted? Even DOS debug could do that (God help us).

              Probably coma or stroke-inducing but strangely quite satisfying in the end.

              We used to do a lot of this when I was a nipper. That and making bitmaps from a bus ticket and a darning needle borrowed from my gran.

  15. Anonymous Coward
    Anonymous Coward

    C++: an octopus made by nailing extra legs to a dog

    "PL/I and Ada started out with all the bloat, were very daunting languages, and got bad reputations (deservedly). C++ has shown that if you slowly bloat up a language over a period of years, people don't seem to mind as much." -- James Hague

    And for even more C++ quotes, see:

    http://harmful.cat-v.org/software/c++/

  16. Anonymous Coward
    Anonymous Coward

    Portability is being forgotten here

    Sutter's claim that the standard gave you portability is revisionist history. To conform to a standard, you need a good set of tests; to benefit from a standard, you need compilers that pass them. Plum-Hall may have had the former but most compilers fell woefully short on the latter. Substantial rework was required going from one compiler to another -- even on the same architecture. It was not pleasant.

    I have not programmed in C++ for a while so I do not even know if conformance results are even available nowadays. Back in the day, Sun's compiler was closest, followed by Borland.

  17. Liam Shepherd
    Unhappy

    "Quicker, cleaner, Java-ier"

    Oh great, so now every application is going to start taking 10 times as much memory....

Page:

This topic is closed for new posts.

Other stories you might like