10 ms·

>"for C++ 98, but I can't motivate myself to get the new edition and learn in the ins-and-outs of C++ 11" I can understand that but keep in mind that C++11 is

>"for C++ 98, but I can't motivate myself to get the new edition and learn in the ins-and-outs of C++ 11" I can understand that but keep in mind that C++11 is a completely different language to what it is C++98.

angersock 12y ago
This is a bug, not a feature. There is a lot of good stuff in the new versions of C++, but the language really could've used a bifurcation years ago. That said, it's still the best tool in the toolbox for certain problems.
- loup-vaillant 12y ago
  Which problems? That's a genuine question: the way I see it, C++'s niche is shrinking by the year, as new languages and more powerful computers arise. So, what's left?
  - vinkelhake 12y ago
    It's not about specific problems, but rather when you can't compromise on performance and still want to raise the abstraction level from C. There are up and coming languages that can claim to compete in that area, but they're still rather immature and/or lack developer support.
    - loup-vaillant 12y ago
      I'm afraid I must insist on specificity: no specific problem means no justification. I understand the abstract reasoning if we had to plan that we might need C++ in the future. But when you're choosing a language now, you always work on a specific problem. So, which specific problems requires you to both optimize the hell out of your CPU and memory, and mostly work at a higher level of abstraction than C? I'll go even further: C + <high-level language of choice> already competes on that front (abstraction + performance). On which specific problems are they not enough, and C++ is required? I'll go even further: there has been a number of C pre-processors spouting up recently. One of them does Lisp-like macros. Another does lambdas. Yet another might address templates. I predict a modern version of "C with classes", which learned from the mistakes of the past (like trying to be compatible at the syntax level). At that point, do you think there will be any specific problem where C++ is still the best choice?
      - deleted 12y ago
        [deleted]
      - falcolas 12y ago
        Game programming. AAA level games require high level performance which can typically not support interpreted languages. They also are complex enough that trying to program them in C would create more problems than they would solve. Granted, many indy games can work by using an embedded interpreter for much of the game logic, but it doesn't take much to run out of computing power at that level and still maintain reasonable (and consistent) frame rates.
      - vinkelhake 12y ago
        > So, which specific problems requires you to both optimize the hell out of your CPU and memory, and mostly work at a higher level of abstraction than C? My sibling here already mentioned AAA game development. Finance is another area where top performance is often required. Performance is the requirement. Being able to work at an abstraction level higher than C is highly desirable. C++ gives you both of those. > I'll go even further: C + <high-level language of choice> already competes on that front (abstraction + performance). On which specific problems are they not enough, and C++ is required? You get a boundary between the "high level" and "performance oriented" parts of the code that is arbitrary and only exists because the high level language performs poorly. There are definite costs to that approach. > I'll go even further: there has been a number of C pre-processors spouting up recently. Cute hacks that are probably not suitable for production use. Let's be honest here. You're asking for problems that require the use of C++ now. The situation is surely going to be different in, say, five years from now - though I don't think it'll be a "C with classes".
        loup-vaillant 12y ago
        I believe Jane Street does High Frequency trading with OCaml. The other examples sound valid, though I have my doubts about batch processing (compression, crypto…). I intend to work an a serious C pre-processor this summer, after I'm finished with my Earley parser. This won't remotely resemble "C with classes". I won't aim for any syntactic compatibility, that was a silly requirement. Heck, I'll probably have Python-like mandatory indentation, reworked operator precedence, an overhauled type syntax, switches that don't fall through… But I will keep semantic compatibility, and a relatively obvious mapping to underlying C code. Coffe-C, not Clojure-C. But even that won't satisfy me. Eventually, I want to make a source-to-source transformation framework that can turn any language into any other. With that, languages become less of a programming interface, and more of an implementation concern.
  - cageface 12y ago
    I write music-making software, which is one domain where C++ is utterly dominant and likely to remain so for a long time. In this world you need a language that's fast, gives you fine-grained control of memory, and allows you to operate without ever allocating or taking a lock of any kind. You could also use C for this, and some people do, but I find that the more powerful abstractions C++ provides are very very helpful here. I think it's unlikely we'll see anything like Chrome, Ableton Live, or Photoshop written in anything but C++ any time soon.
    - pcwalton 12y ago
      > I think it's unlikely we'll see anything like Chrome, Ableton Live, or Photoshop written in anything but C++ any time soon. We are working to change that in Servo :)
      - cageface 12y ago
        I'm rooting heavily for you guys. I use C++ not because I love it but because it's my only reasonable option. If Rust becomes viable for the work I do I'll be on it in a flash.
        seth1010 12y ago
        There was a guy at the last Rust Seattle meetup that was doing procedural music generation in Rust and said he was having a blast.
    - justincormack 12y ago
      Well Lightroom is not exactly like Photoshop but it is mostly written in Lua. Parts are in C or C++ still it is true.
  - zenbowman 12y ago
    How so? It is still the dominant language for large-scale low-level systems. Critical software driving submarines, power plants, financial exchanges and medical devices is likely written in C++. The code on most of SpaceX's spacecrafts is in C++. Most of Google's infrastructure is written in C++. With the constant increase of low powered computing devices we are likely to see that "niche" increase. I think it is rather embarrassing that most code written in modern languages performs worse on today's computers than native code running on 1980s machines. Performance is what makes computing magical. "In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal and I believe the same viewpoint should prevail in software engineering" - Donald Knuth Sadly, people only cite his other quote about premature optimization being evil, leading to a generation of computer programs written with no consideration of speed and user experience.
    - 59nadir 12y ago
      > It is still the dominant language for large-scale low-level systems. He didn't say it wasn't the least dominant. He asked why it was to be considered the best. Dominance is a thing of legacy and you have to take into account a bunch of reasons that have nothing to do with how good a language is to assess why that's so. Being the best tool is something completely different. I think the commenter has a good point and I think it's clear that a lot of the areas C++ has been used for have been taken over by better languages that offer more without conceding much. In that regard, he is spot on in saying that C++'s niche is indeed shrinking. C++, like most other languages, is the best tool for some problems and areas, but those are growing smaller and smaller as we identify exactly what we need and create new languages to escape the rest of C++.
    - loup-vaillant 12y ago
      Funny how "critical" software often uses wildly unsafe languages. They should take advantage of paranoid type systems instead, that would prevent the occasional crash upon integer overflow, or SI/imperial incompatibility… In established engineering disciplines, specification is a relatively small part of the work. In software, specification is everything (compilers and interpreters do the heavy duty for you). In established engineering discipline, a 12% improvement in a meaningful dimension (such as construction costs, or interior volume, or…) is easily worth doubling the specification effort. In software, a 12% cut in specification effort is easily worth a 50% worsening of another dimension, such as runtime speed or compilation speed (though of course we must not overdo it http://xkcd.com/303/ http://xkcd.com/303/ ).
  - captainmuon 12y ago
    Scientific computing. For my work (in particle physics) I need something that is fast, has interoperability with decades worth of C, C++ and Fortran code, runs preferable close-to-metal, and has minimal overhead. Also, it has to be something physicists (not computer scientists) can/want to work with. There are a lot of great libraries for Python, and it's much nicer and more productive. I use it whenever possible, esp. for making graphics, or when I can use optimized stuff like in numpy. However, most of the programs I write are of the type "loop over 10 million entries, perform a simple calculation, return a number". These are mostly IO bound, and one would think that this is a case where you could use a dynamic or interpreted language. But whenever I tried, the overhead for the large loop and the variable access in tight loops was too high, and the problem became CPU bound. So, in my experience, it has to be a compiled language (or at least something more performant then Python). I'd love to be able to use something like Haskell, as a lot of my problems are functional in nature, and it'd be able to catch a lot of stupid bugs. But it is too esoteric to be realistically adopted by the community. The ideal language for me would be "C+". A C++ lite, where you would ban most of the complications. You would still be able to write C++ libraries, but then use them from simple C+. A C+ user, as opposed to a library writer, would not have to know about the "safe bool idiom", traits, private destructors, default methods (which are utter maddness in C++11) and template metaprogramming. I'd then augment this simplified C+ with a powerful static invariant checker. You could say something like "guarantee x < 10; x = f()" and it could complain "you demanded x be < 10, but f() only guarantees x < 100".
    - loup-vaillant 12y ago
      > I need something that […] has interoperability with decades worth of C, C++ and Fortran code. Assuming you meant more than having a good FFI… When I judge the suitability of a language for a task in the abstract, I systematically ignore 2 very important factors: legacy code, and skill availability. I do as if everyone know every language, and we start from a mostly blank slate. If I didn't ignore those factors, I wouldn't be judging the languages, I would be judging whole ecosystems, introducing a huge status-quo bias in the process. --- The C+ you look for is probably possible. I bet it could be implemented a la CFront.
    - mmaldacker 12y ago
  - TheCondor 12y ago
    Writing certain windows apps? The paper states that C++ must have done something right, as it is still consistently popular. If ms didn't go all in with it though, I think it would be a footnote in history.
    - loup-vaillant 12y ago
      > The paper states that C++ must have done something right, as it is still consistently popular. Oh, yes it did. Mainly preying on human irrationality. Most notably status-quo bias, exploited with its embrace and extend strategy.
  - 72deluxe 12y ago
    Cross platform applications? I know that C# apparently has cross platform support but I met with limited success on Mac OSX (perhaps I didn't try hard enough). It is fairly easy to get a cross-platform library and use C++ to write for the main OSes (Mac OSX, Windows, Linux, in no particular order) and then you can also take the same code and compile and run it on your Raspberry Pi and ARM systems. I know you could probably do the same with Python but I think small systems would suffer a speed penalty (I even find desktop Python applications slow so I dread to think of GUIs on an ARM written in Python). I reality I have not ever come across a piece of paid software that included a runtime of Python or some scripting language other than Perl, and that clearly wasn't for a GUI app. What else would you write for all three platforms in? Java? I am curious. (I suppose if you are targeting one platform only, then it might make sense to write in languages typically tied to that platform, eg. Obj-C / Swift / VB / C# (as is vastly popular in Windows land)).
norswap 12y ago
It's different in the sense that it adds a whole lot of features, which makes it even more complex. It's not just the new features, but how they interact with old one. C++98 is still there, just underneath.
- pradn 12y ago
  The addition of a whole host of features in C++11 makes the language more consistent and easier to comprehend. The talk gives examples of this (auto variables, range for loops, etc.)
  - georgemcbay 12y ago
    Of course, as soon as you have to use any external libraries written for C++98 you are right back to having to understand both. I, thankfully, haven't used C++ much in the past few years after using it nearly exclusively for about a decade, but the one thing about working in it that will always stick with me is how virtually every project would eventually have like 8 different string classes contained within it for much the same reason (different libraries and/or OS level APIs would use different string classes, often their own), and this is well after std::string/wstring were a thing. That's the real danger with a sprawling language like C++, IMO. Not that you have to use every bit of it in your own code (in your own code you can get by with a very small subset), but the fact that because there's little true consensus on which bits of it to use it, projects with external dependencies (that are also in C++) generally grow to use not only the entire language and standard library in different places, but also a bunch of badly hacked up reimplementations of the standard library that come along with some of those dependencies.
    - humanrebar 12y ago
      The problem with string classes, including std::string, is that they are object oriented. The things you do with a string should be orthogonal to how the string works. When you think about it std::string is really a string buffer. And if we had good string algorithms, it wouldn't be much more useful than vector<char>. In various circumstances you may want: string_views, copy_on_write_buffers, small_buffers (for small-string optimization), native arrays of chars, std::arrays of chars, std::vectors of chars, tries, and so on. In all of the above cases, you should be able to write: auto firstSpace = std::find( begin(myCharContainer), end(myCharContainer), ' '); ...to get an iterator to the first space in your container. And on top of all that, you could make versions of begin() and end() that return iterators that respect various character encodings.

angersock 12y ago

This is a bug, not a feature. There is a lot of good stuff in the new versions of C++, but the language really could've used a bifurcation years ago. That said, it's still the best tool in the toolbox for certain problems.

loup-vaillant 12y ago
Which problems? That's a genuine question: the way I see it, C++'s niche is shrinking by the year, as new languages and more powerful computers arise. So, what's left?
- vinkelhake 12y ago
  It's not about specific problems, but rather when you can't compromise on performance and still want to raise the abstraction level from C. There are up and coming languages that can claim to compete in that area, but they're still rather immature and/or lack developer support.
  - loup-vaillant 12y ago
    I'm afraid I must insist on specificity: no specific problem means no justification. I understand the abstract reasoning if we had to plan that we might need C++ in the future. But when you're choosing a language now, you always work on a specific problem. So, which specific problems requires you to both optimize the hell out of your CPU and memory, and mostly work at a higher level of abstraction than C? I'll go even further: C + <high-level language of choice> already competes on that front (abstraction + performance). On which specific problems are they not enough, and C++ is required? I'll go even further: there has been a number of C pre-processors spouting up recently. One of them does Lisp-like macros. Another does lambdas. Yet another might address templates. I predict a modern version of "C with classes", which learned from the mistakes of the past (like trying to be compatible at the syntax level). At that point, do you think there will be any specific problem where C++ is still the best choice?
    - deleted 12y ago
      [deleted]
    - falcolas 12y ago
      Game programming. AAA level games require high level performance which can typically not support interpreted languages. They also are complex enough that trying to program them in C would create more problems than they would solve. Granted, many indy games can work by using an embedded interpreter for much of the game logic, but it doesn't take much to run out of computing power at that level and still maintain reasonable (and consistent) frame rates.
    - vinkelhake 12y ago
      > So, which specific problems requires you to both optimize the hell out of your CPU and memory, and mostly work at a higher level of abstraction than C? My sibling here already mentioned AAA game development. Finance is another area where top performance is often required. Performance is the requirement. Being able to work at an abstraction level higher than C is highly desirable. C++ gives you both of those. > I'll go even further: C + <high-level language of choice> already competes on that front (abstraction + performance). On which specific problems are they not enough, and C++ is required? You get a boundary between the "high level" and "performance oriented" parts of the code that is arbitrary and only exists because the high level language performs poorly. There are definite costs to that approach. > I'll go even further: there has been a number of C pre-processors spouting up recently. Cute hacks that are probably not suitable for production use. Let's be honest here. You're asking for problems that require the use of C++ now. The situation is surely going to be different in, say, five years from now - though I don't think it'll be a "C with classes".
      - loup-vaillant 12y ago
        I believe Jane Street does High Frequency trading with OCaml. The other examples sound valid, though I have my doubts about batch processing (compression, crypto…). I intend to work an a serious C pre-processor this summer, after I'm finished with my Earley parser. This won't remotely resemble "C with classes". I won't aim for any syntactic compatibility, that was a silly requirement. Heck, I'll probably have Python-like mandatory indentation, reworked operator precedence, an overhauled type syntax, switches that don't fall through… But I will keep semantic compatibility, and a relatively obvious mapping to underlying C code. Coffe-C, not Clojure-C. But even that won't satisfy me. Eventually, I want to make a source-to-source transformation framework that can turn any language into any other. With that, languages become less of a programming interface, and more of an implementation concern.
- cageface 12y ago
  I write music-making software, which is one domain where C++ is utterly dominant and likely to remain so for a long time. In this world you need a language that's fast, gives you fine-grained control of memory, and allows you to operate without ever allocating or taking a lock of any kind. You could also use C for this, and some people do, but I find that the more powerful abstractions C++ provides are very very helpful here. I think it's unlikely we'll see anything like Chrome, Ableton Live, or Photoshop written in anything but C++ any time soon.
  - pcwalton 12y ago
    > I think it's unlikely we'll see anything like Chrome, Ableton Live, or Photoshop written in anything but C++ any time soon. We are working to change that in Servo :)
    - cageface 12y ago
      I'm rooting heavily for you guys. I use C++ not because I love it but because it's my only reasonable option. If Rust becomes viable for the work I do I'll be on it in a flash.
      - seth1010 12y ago
        There was a guy at the last Rust Seattle meetup that was doing procedural music generation in Rust and said he was having a blast.
  - justincormack 12y ago
    Well Lightroom is not exactly like Photoshop but it is mostly written in Lua. Parts are in C or C++ still it is true.
- zenbowman 12y ago
  How so? It is still the dominant language for large-scale low-level systems. Critical software driving submarines, power plants, financial exchanges and medical devices is likely written in C++. The code on most of SpaceX's spacecrafts is in C++. Most of Google's infrastructure is written in C++. With the constant increase of low powered computing devices we are likely to see that "niche" increase. I think it is rather embarrassing that most code written in modern languages performs worse on today's computers than native code running on 1980s machines. Performance is what makes computing magical. "In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal and I believe the same viewpoint should prevail in software engineering" - Donald Knuth Sadly, people only cite his other quote about premature optimization being evil, leading to a generation of computer programs written with no consideration of speed and user experience.
  - 59nadir 12y ago
    > It is still the dominant language for large-scale low-level systems. He didn't say it wasn't the least dominant. He asked why it was to be considered the best. Dominance is a thing of legacy and you have to take into account a bunch of reasons that have nothing to do with how good a language is to assess why that's so. Being the best tool is something completely different. I think the commenter has a good point and I think it's clear that a lot of the areas C++ has been used for have been taken over by better languages that offer more without conceding much. In that regard, he is spot on in saying that C++'s niche is indeed shrinking. C++, like most other languages, is the best tool for some problems and areas, but those are growing smaller and smaller as we identify exactly what we need and create new languages to escape the rest of C++.
  - loup-vaillant 12y ago
    Funny how "critical" software often uses wildly unsafe languages. They should take advantage of paranoid type systems instead, that would prevent the occasional crash upon integer overflow, or SI/imperial incompatibility… In established engineering disciplines, specification is a relatively small part of the work. In software, specification is everything (compilers and interpreters do the heavy duty for you). In established engineering discipline, a 12% improvement in a meaningful dimension (such as construction costs, or interior volume, or…) is easily worth doubling the specification effort. In software, a 12% cut in specification effort is easily worth a 50% worsening of another dimension, such as runtime speed or compilation speed (though of course we must not overdo it http://xkcd.com/303/ http://xkcd.com/303/ ).
- captainmuon 12y ago
  Scientific computing. For my work (in particle physics) I need something that is fast, has interoperability with decades worth of C, C++ and Fortran code, runs preferable close-to-metal, and has minimal overhead. Also, it has to be something physicists (not computer scientists) can/want to work with. There are a lot of great libraries for Python, and it's much nicer and more productive. I use it whenever possible, esp. for making graphics, or when I can use optimized stuff like in numpy. However, most of the programs I write are of the type "loop over 10 million entries, perform a simple calculation, return a number". These are mostly IO bound, and one would think that this is a case where you could use a dynamic or interpreted language. But whenever I tried, the overhead for the large loop and the variable access in tight loops was too high, and the problem became CPU bound. So, in my experience, it has to be a compiled language (or at least something more performant then Python). I'd love to be able to use something like Haskell, as a lot of my problems are functional in nature, and it'd be able to catch a lot of stupid bugs. But it is too esoteric to be realistically adopted by the community. The ideal language for me would be "C+". A C++ lite, where you would ban most of the complications. You would still be able to write C++ libraries, but then use them from simple C+. A C+ user, as opposed to a library writer, would not have to know about the "safe bool idiom", traits, private destructors, default methods (which are utter maddness in C++11) and template metaprogramming. I'd then augment this simplified C+ with a powerful static invariant checker. You could say something like "guarantee x < 10; x = f()" and it could complain "you demanded x be < 10, but f() only guarantees x < 100".
  - loup-vaillant 12y ago
    > I need something that […] has interoperability with decades worth of C, C++ and Fortran code. Assuming you meant more than having a good FFI… When I judge the suitability of a language for a task in the abstract, I systematically ignore 2 very important factors: legacy code, and skill availability. I do as if everyone know every language, and we start from a mostly blank slate. If I didn't ignore those factors, I wouldn't be judging the languages, I would be judging whole ecosystems, introducing a huge status-quo bias in the process. --- The C+ you look for is probably possible. I bet it could be implemented a la CFront.
  - mmaldacker 12y ago
- TheCondor 12y ago
  Writing certain windows apps? The paper states that C++ must have done something right, as it is still consistently popular. If ms didn't go all in with it though, I think it would be a footnote in history.
  - loup-vaillant 12y ago
    > The paper states that C++ must have done something right, as it is still consistently popular. Oh, yes it did. Mainly preying on human irrationality. Most notably status-quo bias, exploited with its embrace and extend strategy.
- 72deluxe 12y ago
  Cross platform applications? I know that C# apparently has cross platform support but I met with limited success on Mac OSX (perhaps I didn't try hard enough). It is fairly easy to get a cross-platform library and use C++ to write for the main OSes (Mac OSX, Windows, Linux, in no particular order) and then you can also take the same code and compile and run it on your Raspberry Pi and ARM systems. I know you could probably do the same with Python but I think small systems would suffer a speed penalty (I even find desktop Python applications slow so I dread to think of GUIs on an ARM written in Python). I reality I have not ever come across a piece of paid software that included a runtime of Python or some scripting language other than Perl, and that clearly wasn't for a GUI app. What else would you write for all three platforms in? Java? I am curious. (I suppose if you are targeting one platform only, then it might make sense to write in languages typically tied to that platform, eg. Obj-C / Swift / VB / C# (as is vastly popular in Windows land)).

norswap 12y ago

It's different in the sense that it adds a whole lot of features, which makes it even more complex. It's not just the new features, but how they interact with old one. C++98 is still there, just underneath.

pradn 12y ago
The addition of a whole host of features in C++11 makes the language more consistent and easier to comprehend. The talk gives examples of this (auto variables, range for loops, etc.)
- georgemcbay 12y ago
  Of course, as soon as you have to use any external libraries written for C++98 you are right back to having to understand both. I, thankfully, haven't used C++ much in the past few years after using it nearly exclusively for about a decade, but the one thing about working in it that will always stick with me is how virtually every project would eventually have like 8 different string classes contained within it for much the same reason (different libraries and/or OS level APIs would use different string classes, often their own), and this is well after std::string/wstring were a thing. That's the real danger with a sprawling language like C++, IMO. Not that you have to use every bit of it in your own code (in your own code you can get by with a very small subset), but the fact that because there's little true consensus on which bits of it to use it, projects with external dependencies (that are also in C++) generally grow to use not only the entire language and standard library in different places, but also a bunch of badly hacked up reimplementations of the standard library that come along with some of those dependencies.
  - humanrebar 12y ago
    The problem with string classes, including std::string, is that they are object oriented. The things you do with a string should be orthogonal to how the string works. When you think about it std::string is really a string buffer. And if we had good string algorithms, it wouldn't be much more useful than vector<char>. In various circumstances you may want: string_views, copy_on_write_buffers, small_buffers (for small-string optimization), native arrays of chars, std::arrays of chars, std::vectors of chars, tries, and so on. In all of the above cases, you should be able to write: auto firstSpace = std::find( begin(myCharContainer), end(myCharContainer), ' '); ...to get an iterator to the first space in your container. And on top of all that, you could make versions of begin() and end() that return iterators that respect various character encodings.