back to article Stroustrup on next-gen C++: I didn't want to let go of my baby

C++ 11 is “far better than previous versions”, says the inventor of the language Bjarne Stroustrup. He was speaking at an online event marking the launch of Embarcadero's C++ Builder XE3, a rapid application tool targeting Windows and Mac OS X. C++ Builder XE3 is a promising but curious product. Delphi and C++ Builder were …


This topic is closed for new posts.


        1. This post has been deleted by its author

  1. Anonymous Coward
    Anonymous Coward

    Large nested macros in C can be very useful. My magnum opus application has survived and evolved over 20 years - starting as a command line Dos program in TurboC. It has been re-organised several times until it became a Visual Studio 6 32 bit console program.

    The vast majority of the code relied on nested C macros for two reasons. Firstly it allowed some extremely complicated expressions to be read as simple logical application orientated statements. Secondly the evolution changed the underlying mechanisms several times - and rewritten macros allowed recompilation without having to make widespread changes elsewhere.

    The most annoying problem with Visual Studio 6 was that it optimised several coincidentally identical functions' bodies to one piece of code with a single entry point. What it should have done was produce unique entry points to a single piece of code.

    Visual Studio .NET would never produce a fully working version of the application - even with all optimisation switched off. Quite what the subtlety might be has not yet been revealed.

    1. dajames Silver badge

      Useful or abuseful?

      Large nested macros in C can be very useful.

      Useful, maybe, but very hard to maintain. A macros has no respect for scope, it can mean different things in different parts of a program. That makes the program hard to read, and so hard to maintain.

      Macros aren't only impenetrable to humans, tools are poor at handling them too. For example: cross-referencing tools typically can't see inside a macro, so will fail to list occurrences of names variables within a macro. Source-code debuggers can't step inside macros.

      All of this makes them too dangerous to use in any non-trivial way.

      1. Nigel 11

        Re: Useful or abuseful?

        In my experience the preprocessor in C and C++ is inadequate for cases where one's program code is best generated by another program. Use a stand-alone macro-processor, or write your own code-generator in (say) Python. Then just build it into your makefile. But do try to make sure that it emits debug-able code!

        1. Anonymous Coward


          very fast, very debuggable code if you have the expanded stuff as files on disk. MUCH faster than the template crapola.

      2. Anonymous Coward
        Anonymous Coward

        Re: Useful or abuseful?

        "That makes the program hard to read, and so hard to maintain."

        In this particular case the inline code was repeated many times for similar, but not identical, imported data structures. Adding a new data case was trivial as the macros generated most of the code.

        When an underlying mechanism was changed then the many data cases required no recoding once it worked for one case. Without macros the number of manual changes required to keep each case in step would eventually have been an impossible "spinning plates" task. That would have guaranteed not only transcription errors - but each would have been unpredictable.

        Trying to read the programs' high level functionality as C was very difficult. Reading it as a set of macro calls was very easy. The macro expansion was relied upon to the same degree that one relies on a compiler producing the intended functionality in machine executable code.

        A new working case could be accurately analysing live data within an hour of receiving the first sample. It was a tool for an environment with rapidly moving goalposts.

        The Quality Assurance certificate stated that only the last fully regression tested binary was certified. Future enhancement or supportability was not guaranteed.

        Horses for courses.

      3. Anonymous Coward
        Anonymous Coward

        Re: Useful or abuseful?

        "For example: cross-referencing tools typically can't see inside a macro, so will fail to list occurrences of names variables within a macro. Source-code debuggers can't step inside macros."

        That deficiency is the fault of the compilers. There was a time when a decent C compiler had the option to retain the preprocessor output files for debugging purposes.

        The same problems exist for bugs that show up in compiler third party supplied libraries, or OS calls. The library binaries used to come with symbol tables and even source for debugging purposes.

        There has always been an economic need to keep development programmers to a narrow horizontal focus. In the old days there was in-house support, with wider skills, who would untangle any problems that appeared outside a developer's skills. Nowadays it often seems that even the suppliers do not have the in-house skills to support the products they sell at that level.

        Even assembler system programmers often had a narrow focus that did not include things like OS task switching or the hardware implementation. They rarely had to know about potential timing problems - so experienced "random" bugs which were actually deterministic in the wider context.

  2. William Boyle
    Thumb Up

    regarding C++ macros

    Honestly, in the past I was a major violator of this principle, but it was out of necessity since I was writing that code before std c++, and templates did not exist. Now, I rarely write macros, and try to limit that to only absolutely necessary cases. Since the invention of the STL, complex C++ macros are mostly unnecessary, and undesirable. Thanks Bjarne for your great work - I am definitely going to plunk down some of my hard-earned $$ and add your book to my library! Stroustrup and Ellis has long had an honored place there - both the original edition as well as the ANSI version. -)

    1. Anonymous Coward

      Not True, IMO

      Templates will make it really hard for debuggers and IDEs to provide a useful debugging experience and to properly navigate code. Whatabout a template class X which accepts a class Y and calls method Y::printYourself(). I doubt that there are IDEs which can properly track this at this time if you want to see all references to Y::printYourself().

      Then, templates are slow as hell to compile.

      Thirdly, template compile errors are 99% noise and 1% signal. Only after having spent 500 hours in front of them you will master the black art of filtering out that 1%. And yes, I mean that absolutely serious and I don't exaggerate.

      Now replace these template classes with m4 macros which are expanded into plain C++ source files as part of the build process. That will allow the IDE to nicely index all of the expanded code, will allow for nice debugging and it will generate sane error messages linked to the actual expanded code.

      I recognise there are some special cases where you need the power of template classes. But my feeling is that 1 out of 10000 use cases justifies the use of templates instead of a proper macro language (m4 being just one of many).

      In most cases, templates are a regression to a proper macro system such as the one I described.

      1. Anonymous Coward

        Plus - Templates Are Non-Orthogonal

        Unix has been successful because it is an assortment of many orthogonal tools which can be combined in an astronomic number of ways - according to problem at hand.

        The C++ compiler and templates are bolting two things together: Programming language and macro language. As always in such cases, the results are highly sub-optimal.

        If they really wanted a full code generation language run at compile time; why didn't they use Perl, Tcl/tk or LISP for that purpose ?? Yeah, because of Not Invented Here.

  3. Dexter

    The idea that C++ is not suitable for embedded systems is a myth.

    C++ code isn't any bulkier or slower than C code. In fact I've seen plenty of C code which ends up longer because it can't use things like virtual functions.

    Of course some features of C++ (notably exception handling and use of the STL) can cause code to bulk up.

    But you don't *have* to use those features; you'd certainly not use the STL for embedded code.

    Exceptions if done correctly (obviously depends on compiler/.code generator) should cause no overhead at all if the exception doesn't fire. If it does fire, you've got a stack unwind to handle, with its associated destructor calls, but that's not much worse than setjmp/longjmp

  4. Anonymous Coward
    Anonymous Coward

    Missing foot.

    It was sh*t when it was invented.

    It was sh*t when it was developed.

    It is still sh*t.

    The 0.001% of developers who need low level sh*t should be bothered. Everyone else should use something else.

    1. M Gale

      Re: Missing foot.

      You mean the 0.001% of developers who want something that's compute-intensive to complete on a timeline somewhat less than from now until the heat death of the universe?

      Those developers?

  5. Pat Volk


    Program languages to many programmers are like guitars to guitar players... Many will go through a bunch in order to find one they can 'play. It's not the instrument, it's the technique. If you have a problem of 100 tires in your yard, bad C practice is to make 1 stack of 100. Bad C++/OO will make 100 stacks of 1. I have had discussions with people quoting Stroustroup like it was the bible. Just because you can do it doesn't necessarily mean you should.

    I've used C++ for embedded, and it's useful (Broadcom has done it well IMHO). I've seen subclassing done backwards more times than I care to (mention scope, they say OO automatically is scoped, as they litter statics through the classes).

    The allure of C++, perl, and other languages is you can create a meta-language to describe the problem you're solving. But often it's jargon, ergot, or some other obscure cant that repackages what's already there. I think that's people not trusting the language, or invoking rituals (in OO, everything must be dynamically allocated... why? ... it's not OO if it's not. So, before I bang my head off the rock).

  6. Anonymous Coward
    Anonymous Coward

    A couple of picoseconds? Really?

    I'm not sure you can get even a modern CPU to do much of anything aside from starting to turn on a bit in a couple of picoseconds - a picosecond is a *really* short amount of time...

    1. mevets

      Re: A couple of picoseconds? Really?

      Maybe that misunderstanding is why C++ is such a dog ass slow and bloated beast. I thought it was more incompetence than ignorance....

    2. Anonymous Coward

      What's "a couple" ?

      Maybe something like 200ps ? (POWER does 5GHz ) Then Mr Stroustrup is correct.

  7. Someone Else Silver badge
    Thumb Up

    Nail, meet hammer

    As languages grow, if they’re owned by a single organisation, sooner or later they start taking on peculiar twists to support that organisation’s business plan. The allies of that corporation are favoured.

    He sure goat that part right. (I'm looking at you, Oracle, and you, Microsoft...)

  8. silent_count

    The thing about C and C++

    C and C++ are similar to assembly language. They are exactly as good or bad as the programmer's discipline. They will not hold your hand, nor will they stop or even discourage you from making horrendous "mistakes". Some programmers prefer to impose discipline upon themselves and love C and C++, while others prefer it to be imposed from without and hate them both.

    I'm not saying the above is true for everyone, or that either approach is right or wrong but that's just how I see it shaking out.

    1. Christian Berger Silver badge

      Re: The thing about C and C++

      That would be perfectly aright, if it was "honest" about it. However if you look into typical C/C++ courses you'll find that it's being taught as some sort of Pascal. Many programmers are being brought up believing that C/C++ are high level languages, they will never understand what their code does.

      Plus C++ is so amazingly complex, very few single persons understand it all.

  9. Philius



  10. TwoWolves

    Most of you just aren't listening to what he's [really] saying

    C++ does seem to be the Marmite of the development community, I do wish people would keep calm about these things.

    I have made a living as a consultant brought in usually at the last minute or after the fact to save projects that have gone awry for various reasons. These have been with a broad range of languages so over the years I've got to see the many ways that languages can be abused.

    The problem with C++ is that it holds the mirror up to the face of the developer at an early stage, and a weak programmer is not likely to like what he sees. Other languages delude by hiding implementation weakness and its this obsequiousness that wins over generations of developers.

    1. Anonymous Coward

      You Nasty, Nasty Elitist !

      Do you really want to say I have to spend more than a year to become an elite software engineer ??

  11. Nigel 11

    Procedural, Object-orientated, and Introspective

    There's a lot of obfuscation out there about what is a very simple concept.

    Procedural: F(a, b);

    Object-orientated: a.F(b)

    The advantage of the latter is that you cannot apply an inappropriate F to argument a, because only the methods of the object a are available in this context. It also reduces the number of pointers or object handles one has to keep track of. Of course, it doesn't prevent all bugs. You can still do (say) a.clockwise(b) when you meant a.anticlockwise(b) or a.clockwise(c)

    Introspective: in a language like Python you might return to the procedural form, but check at runtime about the exact type of argumernts a and b, and do sensible things if they're not as expected.

    1. Christian Berger Silver badge

      Re: Procedural, Object-orientated, and Introspective

      That's the C++/Pascal way of OOP. The normal (e.g. Smalltalk) way is that you have objects, which are more like processes, which send each other messages. So you don't call a function, which means that it's hard to have encapsulation, but you send messages which even works between different computers. (Erlang implements that)

      Then there are languages where you have objects, but can join them. Imagine you wanted to do "make_love". Now is it a.make_love(b) or b.make_love(a)? There you can do make_love(a,b) and the correct make_love will be selected by the compiler (or failing that the runtime).

  12. This post has been deleted by a moderator

    1. Mikko
      Thumb Down

      Re: Macro hell

      Java? The language that has outsourced all the insanity into the build and dependency management systems and the thousand libraries, frameworks and domain-specific languages of varying quality and ancestry, many of which still drown you in AbstractProxyFactoryInterfaceBeans? The language with probably the most lines of bad code written in the past decade? With a dozen tribes gathered around different ecosystems, separated by a common language...

  13. Anonymous Coward
    Anonymous Coward

    C++ - an octopus made by nailing extra legs onto a dog

    C++ - an octopus made by nailing extra legs onto a dog

    -- Jochen Schneider

    (Disclaimer: I have worked on C/C++ compilers. Schneider is too harsh on C and not harsh enough on C++.)

  14. J.G.Harston Silver badge

    "If I make a 10,000 by 10,000 matrix in a function, I can hand it over to you at the cost of two pointer assignments."

    He's only just invented pass-by-reference? I've been doing that for more than 30 years.

  15. nuked

    Yeah, but it's cool to say you can programme in C++...

  16. HBT


    C is a great language.

    C++ started off as a great language (extending C to OOP)

    But once template was introduced to C++,, it descended into a dogs dinner of a language. Hard to understand, hard to implement without a compiler debugger, hard to even read - code looks like an drunken octopus has danced across the non-alphanumeric part of the keyboard. I'm no compiler expert, but I could have done it better,

  17. Periquet dels Palots

    Kettle & Pot

    I find it ironic that Bjarne should complain abot the bad quality of books that teach C++. He should know well, as his own "The C++ Programming Language" is the most unfathomable book ever. It does not pretend to be a learning tool, but a reference tool, I know, but it may as well be written in Sanscrit. The explanations might be a marvel of concission and perfect software engineering, but while I can picture the author jerking off in self satisfaction, for the less gifted like me, they read like infinitely recursive and cross-jumping blabber. Any search for enlightenment tends to become a hopeless expedition into the bowels of the language where the most important discovery is how little you know, how much you ignore, and how difficult it will be to advance.

    So, I have not looked at his new C++ teaching book, but I don't think Mr. Stroustrup's teaching abilities are very brilliant.

    I use C++ every day, and it tends to make me feel I am very stupid. Maybe I am, and that is why I appreciate languages that make me feel smart.

  18. Richie 1

    C++ made me appreciate other languages

    C++ was the first language that I learnt. Rather than putting me off programming (as others have commented), it just made every other language seem easy.

    I love C# for being C++ without the hard bits, and pretty much every scripting language I've tried seems like flying by comparison.

    That said, now I'm no longer a code-newbie, it would be really interesting to revisit C++ and see if it's as tricky as I remember it to be.


This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2019