Forgot your password?
typodupeerror
Programming

An Interview With C++ Creator Bjarne Stroustrup 509

Posted by CmdrTaco
from the add-an-extra-plus dept.
DevTool writes "Bjarne Stroustrup talks about the imminent C++0x standard and the forthcoming features it brings, the difficulties of standardizing programming languages in general, the calculated risks that the standards committee can afford to take with new features, and even his own New Year's resolutions."
This discussion has been archived. No new comments can be posted.

An Interview With C++ Creator Bjarne Stroustrup

Comments Filter:
  • C++0when? (Score:4, Informative)

    by fishexe (168879) on Tuesday January 11, 2011 @03:31PM (#34838840) Homepage
    Of course by this point it really should be called the imminent C++1x standard.
  • by ron_ivi (607351) <sdotno@cheapcomplexdevice s . com> on Tuesday January 11, 2011 @03:42PM (#34838952)

    It seems to me that most tasks that seem good for C++ would be better handled using a mix of an easier-to-program language (Ruby, Python, heck even lisp or smalltalk or anything else) with C extensions.

    IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules. In C you're using a pretty good tool for low-level programmings (especially with a dialect where you can sneak in a few assembly calls where you need to). In Ruby you're using a reasonably nice and efficient to develop in OO language. With the incredible ease of writing C extensions for Ruby, it's easy to use the best tool for each part of the job you're doing. The only compelling reason to use C++ I can think of is if some political policy forces you to use a single language for an entire project; and then I guess C++ not quite as clunky as java or c#.

    ( though I'm kinda repeating myself - a longer rant I made on slashdot about the pains of C++ years ago is here http://slashdot.org/comments.pl?sid=100202&cid=8540772 [slashdot.org] . An even more condemning annoyance about C++ is that thanks to so many convoluted tricks in the language, most people who claim C++ knowledge don't actually know it, as evidenced by the comments in that old thread )

    • by EsbenMoseHansen (731150) on Tuesday January 11, 2011 @03:54PM (#34839074) Homepage

      I tried to use ruby for a while, but ended up back with C++. I couldn't live without static typing, as it turned out, and also C++ had more libraries leading to faster development (for me, at least).

      C++ is the worst language, excepting every other language I have tried. And I am happy about the new features, they should make coding much nicer.

    • The only compelling reason to use C++ I can think of is if some political policy forces you to use a single language for an entire project;

      I think you answered your own question there.

      I've found that a lot of 'outsourced' programming jobs go to people who only know one language. And that language tends to be C++, because its easier to teach someone 1 language than it is to teach them the theory and how it applies to 5 languages.

    • by godrik (1287354) on Tuesday January 11, 2011 @04:01PM (#34839156)

      I aggree that people tend to do too many things in C++ (me first). However, there are quite some place where C++ should be used. Mainly gaming engines and high performance computing. You NEED low level programming to deal with that. They could be written in C. But numerous C++ programming techniques (mainly template mechanism) makes it much easier to program. You could not get reusable algorithm accross multiple data type with efficient compile-time type checking at no runtime cost without templates. You could do it with macros but you will have terrible compilation problem if you screw up. Or you could use inheritance but will pay the cost at runtime.

      • by derGoldstein (1494129) on Tuesday January 11, 2011 @04:57PM (#34839748) Homepage
        C++ allows you to work at a level of abstraction that you need right now, for this function or section/area of the program. It gives you this ability while not forcing you to inline other languages, but you *can* compile C alongside it in cases where there's already a C library that does specifically what you want (and almost all task-specific libs are written in C, across most languages). No other language can boast anything near this level of flexibility. Can it be messy? Definitely. But good software structures will look clean and logical no matter where you look along the spectrum of abstraction ("spectrum of abstraction"... I need to remember that next time I publish something intended for academia...).
    • by robbyjo (315601)

      Yes. C++ (and Java) are indispensable for scientific software. In scientific software, the spec is ever changing as the science progresses and hence the flexibility to morph the programs as needed and maintainability are of paramount importance. On the other hand, we need the speed.

      Some of these can be resolved by invoking ready-made C libraries and then called in higher level languages such as Python or R or Matlab. However, in many occasions, this luxury isn't available (e.g., Markov Chain Monte Carlo sim

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      No offense but you have to be stupid to not know what + does. If it does something unexpected, chances are you wrote it incorrectly yourself, or are using a terrible library that has undocumented operators that are working incorrectly on top of that. It's not the languages fault when programmers code like retards.

    • You have to take into account the absolute pain which is to manage a multi-language project, let alone debug any problem. Moreover, the level of mind-numbing bloatedness which interpreted languages such as those you described (ruby, python and the like) may, in your opinion, make a language a bit easier to program in, but in practical terms it leads to terribly bloated software which, unless you are running a high end desktop, runs mind-numbingly slow when compared with native, 100% C++ apps.

    • by mswhippingboy (754599) on Tuesday January 11, 2011 @04:32PM (#34839464)

      It seems to me that most tasks that seem good for C++ would be better handled using a mix of an easier-to-program language (Ruby, Python, heck even lisp or smalltalk or anything else) with C extensions.

      IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules. In C you're using a pretty good tool for low-level programmings (especially with a dialect where you can sneak in a few assembly calls where you need to). In Ruby you're using a reasonably nice and efficient to develop in OO language. With the incredible ease of writing C extensions for Ruby, it's easy to use the best tool for each part of the job you're doing. The only compelling reason to use C++ I can think of is if some political policy forces you to use a single language for an entire project; and then I guess C++ not quite as clunky as java or c#.

      ( though I'm kinda repeating myself - a longer rant I made on slashdot about the pains of C++ years ago is here http://slashdot.org/comments.pl?sid=100202&cid=8540772 [slashdot.org] . An even more condemning annoyance about C++ is that thanks to so many convoluted tricks in the language, most people who claim C++ knowledge don't actually know it, as evidenced by the comments in that old thread )

      I disagree on several points. C is great for low level programming, but many times you want to use OO rather than procedural programming. C++ allows you to do exactly the same low level programming you can do in C (including inline-assembler if needed), but also offers the ability to design in OO. I can't think of a good reason not to use C++ rather than C unless it is a simple monolithic (preferably small) project. Mixing languages brings a whole other set of headaches (including staffing issues). Ruby, Python or other languages are fine and have their place, but I can't imagine using them for systems level programming anymore than I would use C++ to build a web application. Languages like Python, Ruby, (errr.. LISP? - there is considerable debate over whether LISP is even a true "programming language" but rather an alternate implementation of a Turing machine, but I digress) are orders of a magnitude too slow to be used as systems programming languages.

    • by EvanED (569694) <evaned&gmail,com> on Tuesday January 11, 2011 @04:34PM (#34839484)

      I used to be a huge C++ fan, though that has waned over the years as I've used better-designed languages and have also seen other people struggle with C++'s testier features.

      That said -- I'd still take C++ over plain C for essentially anything in a heartbeat. (Basically the only exception would be stuff like microcontroller programming or other environments where there isn't really a good C++ compiler.) RAII alone is enough to seal that deal.

      I don't buy most of the arguments of C over C++. For instance, take your statement that "IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules."

      But with modern compilers, I feel it's already very not obvious what the compiler is going to do with your code. What function calls are inlined? What loops are unrolled? For what I think is a reasonably dramatic example of this, take the following snippet:

      int main(int argc, char** argv) {
          int y = 50;
          if (argc > 1) {
              y = 100;
          }
          return y;
      }

      and compile with optimization on. Look at the resulting assembly. There's no branch! (I'm assuming a variant of x86 or x64 here.)

      If you're on a 64-bit system with GCC you'll probably see a cmov (conditional move) instruction, which kind of makes sense. But you don't even need that instruction to be available for it to omit an actual control-flow jump. Recompile with -m32 and look at the assembly again. Much longer, but still no branch. Instead, it uses one of the setxx instructions (setg in my case) and a bit of bit twiddling.

      In my opinion, today's optimizers make the generated code so far removed from what you type into your editor that saying "+ can do anything!" is a drop in the bucket.

      • I don't think the point was what sort of optimizations might be employed or what the resulting binary would look like. It's not about implementation, it's about semantics.

        For instance, in C, the bit shifting and boolean operators have precise and well-defined meanings. I know that anything which compiles with one of those operators is going to do exactly what that operator says. I personally don't have a problem with operator overloading (and truly miss it in Java), but in C++, the standard library co-opts

    • by Prune (557140)
      Indeed, C++ is just as easy as C to use for low-level programming, as not only do you have the option of inline assembly which mixes easily with the rest of your code, but you even rarely need to resort to it as in the major compilers (MSVC, gcc, Intel C++) there is a plethora of compiler intrinsics which almost directly map to assembly instructions while providing a type-safe interface. It's quite easy to write synchronization primitives, for example, using interlocked operation intrinsics--while the same
    • by Spykk (823586) on Tuesday January 11, 2011 @04:46PM (#34839610)
      If you don't like operator overloading then don't use it. I don't see how that has any effect on C++'s usefulness as a low level language. C++ can use inline assembly the same way C can. C++ has all the power of C with the convenience of classes.

      There is no mandate that you must use templates or operator overloading in C++. If you are going to complain that it gives you the option then why aren't you complaining about C having goto?

      In my experience when someone wants to use C over C++ for a new project it is generally because they don't know C++.
      • by firewrought (36952) on Tuesday January 11, 2011 @06:21PM (#34841132)

        If you don't like $FEATURE then don't use it.

        I always cringe when I see this statement in a discussion about programming languages. The presence or absence of a particular feature will impact the third-party libraries you use, the code samples and tutorials you come across, and the legacy apps you inherit. Even if you develop in a vacuum, some features can impact you by accident [operator overloading isn't a good example, but implict-conversion-of-numeric-types-to-boolean is].

        In $FEATURE desirable or not for a particular programming language? Most always, that's going to be a complex usability/design question answerable by some combination of analysis, research, experience, testing, etc. Read the programming languages weblog [lambda-the-ultimate.org] or the discussion forums for D, Haskell, etc., to see the level of thought that goes into make these tradeoffs.

  • Make it stop..... (Score:4, Interesting)

    by jythie (914043) on Tuesday January 11, 2011 @03:46PM (#34838984)
    Stop trying to add more redundant features to C++... it is already getting progressively harder for C++ programmers to read each other's code and teach newbies what something means.

    All this does is result in yet more more syntactic sugar to teach people in order to accomplish the same tasks they can already do with the older standards, and yet another round of relearning so you can tell what someone who learned a 'neat new trick' is doing. And of course you STILL need to teach the old methods to newbies so they can understand C++ code that they have to maintain.

    Seriously.. this really does not help.
    • Some of us wants them. For you that do not, pass std=c++98 to gcc and be happy. Think of it as a new language :)

      • by jythie (914043)
        The problem with this is, we end up with a fractured language were 'I know C++' communicates less and less to a potential employer or team. One of the nightmares I had dealing with a C++ project even a few years ago was everyone's code looked (and worked) so differently according to when they learned the language to the point they could not maintain each others code. The only solution ends up being forcing a standard of 'which version of C++ we will use', which then results in holy wars and retraining whe
        • This will be the, what, second standard? Third? And besides the new libraries, it's not that many new hard-to-grok features that are added. Actually, I can only think of lambda, but a language without lambda is an atrocity. Is there any particular feature you are thinking of? Have you read the wikipedia page?

          I have worked on a number of projects, usually as some sort of project lead or technical lead. I have had problems with people who could not grok C++ (though not many), but I have not had the problem y

        • by Prune (557140)
          This can go either way. I've interviewed people who, when asked to write a test program, produced a C program disguised as C++--with all the old-fashioned C crap like variables declared at the top of the function etc.
          • by lgw (121541) on Tuesday January 11, 2011 @05:04PM (#34839862) Journal

            Well, variable declared at the top of the function are the least evil c-ism. The real problem is a lack of understanding of RAII, and a fear of exceptions. The last time I read Googles C++ coding standards I died a little inside. People just don't "get" C++ for some reason.

            • Those ARE atrocious, are they not? Personally, my coding standing are usually "types looks like this, member variables like this, code nice".

              Of course, the last bit takes a bit for people to learn, but it works nicer than a detailed standard, in my experience.

    • by Korin43 (881732)

      Some of us like it when language designers make things easier for us.


      for each(int i : some_container) { // do things
      }

      vs:


      for(std::container_type::iterator i = some_container.begin(); i != some_container.end(); i++) { // do things
      }

      One of those is immediately obvious and one takes a second to think about. Who cares if you have to learn one new piece of syntax in a language you'll use for decades?

      That said, I see the standard library improvements as more interesting (mainly multithreading and hash tables). Sure

      • by Korin43 (881732)

        Er.. for the "for each" part, I mean just "for". I was confused by Microsoft extentions.

      • by russotto (537200)

        for(std::container_type::iterator i = some_container.begin(); i != some_container.end(); i++) { // do things
        }

        This is just one of MANY reasons C++ needs to die. Just about every interaction with the STL is like this. And suppose you're going through multiple parallel containers (what python calls "zip")? Then the new sugar doesn't work except for one container.

        C++ is the language which allows you to just about anything, but nothing that is all of complex, clear, and efficient. No amount of hacked-on extr

        • by Korin43 (881732)

          Sounds like they could fix that by adding a 'zip' function ;)

        • And suppose you're going through multiple parallel containers (what python calls "zip")? Then the new sugar doesn't work except for one container.

          The sugar is meant for a simple case, just like Python's "for". When you need something more complicated, then - again, as in Python - you use a library solution. In case of zipping two sequences together, you'd use a zip_iterator [boost.org]. In general, you can also simplify many STL patterns by using Boost range library.

          And STL is unwieldy mainly because of the need to explicitly spell out types everywhere. With auto in C++0x, most STL operations are much more concise.

    • You can already do it all with assembler, so it's all syntactic sugar. Presumably, they add it where they believe it will result in a net benefit. If you read the interview, you'll find there aren't many significant features, more refinement of current ones. R-value references seem the main addition, but this is mostly of interest to library authors (as most features are); users simply get cleaner library interfaces to use, not having to worry as much about avoiding copying of large objects.
      • by russotto (537200)

        You can already do it all with assembler, so it's all syntactic sugar. Presumably, they add it where they believe it will result in a net benefit.

        The problem is it's been added in a haphazard way. This is a language where a major feature (template metaprogramming) occurred _by accident_.

    • I do not agree. most of the changes are good, and really needed. They will make programs easier to read and add expressiveness. How can you be against things like auto variables and lambda expressions?

    • by Prune (557140)
      Taking the "syntactic sugar" argument to its conclusion, everything above machine language is syntactic sugar. Accomplish the same task you can already do with an older standard? You can accomplish the same task with any turing-complete language. Such as assembly. Basically, your argument fails a pretty basic sanity check because, by extension, it implies that punched cards are as good as a high-level language.
    • Re:Make it stop..... (Score:4, Interesting)

      by js_sebastian (946118) on Tuesday January 11, 2011 @06:45PM (#34841394)

      Stop trying to add more redundant features to C++...

      Did you even bother to read about what these supposedly "redundant" new features are? Personally, I think these redundant new features will help maintain C++ as one of the 2 or 3 most used programming languages for the next decade. Especially since this time all of the new features already have reference implementations, so the compilers will be very quick to implement them (GCC already supports a long list of them).

      I would say the single most important feature is finally having standard support for threading and concurrency. Hopefully, this will gradually lead to a standard library of high-level abstractions for parallel programming as well as concurrent algorithms (did you ever try the parallel mode of the gnu stl? parallel sort on 8 cores is sweet...).

      There are also a lot of little tweaks under the hood, that programmers will benefit from even if they never need to know about it, just by using the STL. For instance even if you have never heard of move constructors, they will make some methods of standard containers more efficient and make it possible to have a proper implementation of the new unique_ptr (useful for Resource Acquisition Is Initialization paradigm). And most of the added syntax is straightforward enough that it doesn' t really add complexity:

      Initializer lists:

      vector<string> v = { "xyzzy", "plugh", "abracadabra" };

      Range-based for+auto types:

      for (auto x: my_container) {
      ...
      }

  • Interview (Score:5, Funny)

    by Mongoose Disciple (722373) on Tuesday January 11, 2011 @03:55PM (#34839078)

    I always preferred this [chunder.com] interview with Bjarne Stroustrup.

    (Yes, I know it's not real, but...)

    • Re:Interview (Score:5, Insightful)

      by Prune (557140) on Tuesday January 11, 2011 @04:26PM (#34839394)
      I wrote C for about 5 years and then switched to C++ with which I've stuck for the last dozen years. With that perspective, the article you linked to is such a lousy attempt at humor that it made me cringe. C++ has, like many other large entities with significant history, become a bit messy due to the need for legacy support given its huge installed base. This does not mean that you cannot write neat programs with it! It's easy to blame the language instead of the software developer. It is just a matter of a bit of attention and discipline to do great stuff with C++ even while using what some may refer to its more esoteric features like template metaprogramming etc. I could never give up things like multiple inheritance, which may require a bit of care during usage, but I've found to be the way to go in many situations. The majority of the C++0x additions are very welcome as well. What's really needed is a completely modern reference text that minimizes time spent on legacy issues. It's basically the same situation with OpenGL, which has become much larger in the 3.x and 4.x versions, while still supporting all the legacy code--and there is no proper reference so one usually sees a messy mix of 2.x and 3/4.x in most current projects, rather than a clean, organized design following the most recent variant. A proper text (other than the standards document itself) would make a huge difference.
  • by LordNacho (1909280) on Tuesday January 11, 2011 @03:56PM (#34839092)

    See-plus-plus-zero-ex doesn't really roll off the tongue. How about something a bit easier? Super-C, C-flat, Cmega+ or something lame that people can actually say.

    (Here's your queue to explain to me what the proper pronunciation is. AND the reason for picking such a weird name)

  • by Anonymous Coward on Tuesday January 11, 2011 @04:10PM (#34839258)

    Interviewer: Well, it's been a few years since you changed the
    world of software design, how does it feel, looking back?

    Stroustrup: Actually, I was thinking about those days, just before
    you arrived. Do you remember? Everyone was writing 'C'
    and, the trouble was, they were pretty damn good at it.
    Universities got pretty good at teaching it, too. They were
    turning out competent - I stress the word 'competent' -
    graduates at a phenomenal rate. That's what caused the
    problem.

    Interviewer: Problem?

    Stroustrup: Yes, problem. Remember when everyone wrote Cobol?

    Interviewer: Of course, I did too

    Stroustrup: Well, in the beginning, these guys were like demi-gods.
    Their salaries were high, and they were treated like
    royalty.

    Interviewer: Those were the days, eh?

    Stroustrup: Right. So what happened? IBM got sick of it, and
    invested millions in training programmers, till they were a
    dime a dozen.

    Interviewer: That's why I got out. Salaries dropped within a year,
    to the point where being a journalist actually paid better.

    Stroustrup: Exactly. Well, the same happened with 'C' programmers.

    Interviewer: I see, but what's the point?

    Stroustrup: Well, one day, when I was sitting in my office, I
    thought of this little scheme, which would redress the
    balance a little. I thought 'I wonder what would happen, if
    there were a language so complicated, so difficult to learn,
    that nobody would ever be able to swamp the market with
    programmers? Actually, I got some of the ideas from X10,
    you know, X windows. That was such a bitch of a graphics
    system, that it only just ran on those Sun 3/60 things.
    They had all the ingredients for what I wanted. A really
    ridiculously complex syntax, obscure functions, and
    pseudo-OO structure. Even now, nobody writes raw X-windows
    code. Motif is the only way to go if you want to retain
    your sanity.

    Interviewer: You're kidding...?

    Stroustrup: Not a bit of it. In fact, there was another problem.
    Unix was written in 'C', which meant that any 'C' programmer
    could very easily become a systems programmer. Remember
    what a mainframe systems programmer used to earn?

    Interviewer: You bet I do, that's what I used to do.

    Stroustrup: OK, so this new language had to divorce itself from
    Unix, by hiding all the system calls that bound the two
    together so nicely. This would enable guys who only knew
    about DOS to earn a decent living too.

    Interviewer: I don't believe you said that...

    Stroustrup: Well, it's been long enough, now, and I believe most
    people have figured out for themselves that C++ is a waste
    of time but, I must say, it's taken them a lot longer than I
    thought it would.

    Interviewer: So how exactly did you do it?

    Stroustrup: It was only supposed to be a joke, I never thought
    people would take the book seriously. Anyone with half a
    brain can see that object-oriented programming is
    counter-intuitive, illogical and inefficient.

    Interviewer: What?

    Stroustrup: And as for 're-useable code' - when did you ever hear
    of a company re-using its code?

    Interviewer: Well, never, actually, but...

    Stroustrup: There you are then. Mind you, a few tried, in the
    early days. There was this Oregon company - Mentor
    Graphics, I think they were called - really caught a cold
    trying to rewrite everything in C++ in about '90 or '91. I
    felt sorry for them really, but I thought people would learn
    from their mistakes.

    Interviewer: Obviously, they didn't?

    Stroustrup: Not in the slightest. Trouble is, most companies
    hush-up all their major blunders, and explaining a $30
    million loss to the shareholders would have been difficult.
    Give them their due, though, they made it work in the end.

    Interviewer: They did? Well, there you are then, it proves O-O
    works.

    Stroustrup: Well, almost. The executable was so huge, it took
    five minutes to load, on an HP works

  • And, we all know that power corrupts. So, when Joe Shortcut figures out that he can overload the '=' operator to slice his ham sandwich, you invariably end up with illogical, non-intuitively behaving code. Plus, the language in an effort to be ultimately configurable, doesn't take care of some menial, repetitive tasks. That opens the door for insanely dangerous, obscure bugs like object slicing. I wish that the standards community would have just drawn a line in the sand and said "OK, here's the cleaned

    • I never understood the first complaint. Yes, you can make = or + or whatever do crazy thing you like, but that goes for every function call. I remember debugging some (Java code, but that is besides the point) where the programmer had decided that getFoo() should actually change the internal state of the object in such a way that calling getFoo() twice totally screwed up the program. That was every bit as bad as if he has overloaded operator- to do the same.

      Slicing, I agree, is a real problem, though I hav

  • Linking (Score:4, Interesting)

    by MrEricSir (398214) on Tuesday January 11, 2011 @04:13PM (#34839276) Homepage

    The biggest beef I have with C++ is linking.

    Linking to a library that was compiled in a different C++ compiler (or even a different version of the compiler you have) is somewhere between painful and downright impossible; this is because function name mangling was never standardized and the core libraries are often incompatible.

    Couldn't they standardize this in C++? It would make life so much nicer for those who deal in binaries.

    • Re:Linking (Score:5, Informative)

      by shutdown -p now (807394) on Tuesday January 11, 2011 @05:15PM (#34840044) Journal

      It can't be standardized in the language spec itself, because there's no notion of "object files" or even "linking" in general in the spec - it's not tied to a particular implementation technique. That's why you can actually write a conformant C++ interpreter.

      Now a separate standard for C++ ABI is quite possible, and they do, in fact, exist. The trick is getting the compilers to subscribe to them, and the problem is that they already have their existing ABI (usually incompatible with other vendors), and moving to standardized ABI would break compatibility with libraries compiled with older compiler versions. It's not a big deal in Unix world where source code is generally available these days, which is why Unix compilers (e.g. g++ and Intel) converged on a common one; but Windows stuff is still broadly incompatible.

  • by hackingbear (988354) on Tuesday January 11, 2011 @04:15PM (#34839294)
    According to Wikipedia, "C++0x" is pronounced "see plus plus oh ex" [wikipedia.org]. After three rounds of macro preprocessing, four expansions of template substitutions, and reversing five levels of dynamic cast operator overloads, the name is eventually compiled to something readable: C plus plus? Oh, my ex-programming language!.
    • by Prune (557140)
      I often wish Slashdot had an option whereby one could hide all posts moderated as 'Funny'--after all, it's Slashdotters making a judgment of humor...
      • Look at your comment preferences. You can change the value that is assigned to comment moderation. Funny is at +1. Just change it to -5 and you'll never see another "funny" post.

Scientists will study your brain to learn more about your distant cousin, Man.

Working...