6 ms·

Dr. Stroustrup took a lot of pain to ensure the language was useful and did not break backward compatibility. He also always maintained that if you don't use a

Dr. Stroustrup took a lot of pain to ensure the language was useful and did not break backward compatibility. He also always maintained that if you don't use a feature you shouldn't pay for it (in terms of performance). Eventually, it became even more popular and there is now a whole organisation behind the international standards for the language. The book "The Design and Evolution of C++" helps one understand why some things are the way they are and sometimes it helps understand why some things exist in the language in the first place. The language takes a lot of flak but I think it is quite good given the constraints it has and the modern version is an amazing leap forward in ease of use as well.

Underqualified 8y ago
I always felt that if you wanted the same functionality as c++ in terms of performance, flexibility and power of abstraction, you'd end up with something as complex as c++. Modern c++ shows there was/is room for improvement, but it does not fundamentally simplify the language imo.
- unrealhoang 8y ago
  Only if it need to have backward compatibility. Rust doesn’t so it can be vastly simpler.
  - okasaki 8y ago
    How is Rust simpler than C++?
    - virtualritz 8y ago
      Are you talking about grokking the language and its more excotic concepts or writing code on it? I have almost 30 years of C++ experience and about 6 months of Rust. My gut feeling is that the languages are equally difficult to understand but that the experience of writing code in them is very different. I'm sure Rust will have its own set of surprises as I keep using it. But I can't believe they will be nearly as bad as those that C++ comes with. ;)
    - smaddox 8y ago
      Rust is a much smaller language and stdlib than C++ (though still quite large). Rust makes an effort to make many things explicit that are implicit in C++, such as numeric type conversions. Rust's traits are conceptually simpler than classes, especially if you want multiple inheritance. Rust's templates/generics are much closer to the core language than C++'s template language. And then there are all of the safety features of Rust; while there is a learning curve, it is much easier to learn the concepts of lifetimes and ownership when the compiler is helping to enforce proper usage.
  - deaddodo 8y ago
    I love Rust. Especially for emudev and embedded development (fields I would traditionally use C or C++). However, it still performs worse than C++ in most cases [1]. [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
    - dralley 8y ago
      A number of those C++ benchmarks are "cheating" by using SIMD intrinsics, which was only stabilized in Rust about two weeks ago.
      - igouy 8y ago
        1) Specifically which of those C++ programs? Innuendo is not OK. 2) Even with cheating in scare quotes, name-calling is not OK.
        ben509 8y ago
        It's not innuendo when you consider the inherent problems with benchmarks. Once you have an algorithm, it's so hard to define what an objective benchmark is that you should assume the implementation is cheating, even if you wrote it. I say this from personal experience; in one case I was doing timing studies to solve performance problems, and wound up fooling myself by measuring the wrong thing! In this case, is it fair to use SIMD intrinsics? It depends on what you're trying to measure. I think that's why "cheating" is in scare quotes, because what would be cheating in one context might be useful information in another. For instance, if C++ is providing SIMD intrinsics, it's going to beat other languages, and if I just want current performance statistics, that's the question I want to answer. If the question is, "what's the overall quality of the code delivered by the compiler / optimizer" then using specific tricks doesn't give me a good answer.
        igouy 8y ago
        > …when you consider the inherent problems with benchmarks… dralley's comment does not do that. There's nothing difficult here: simply say that those X of N leading C++ programs use SIMD intrinsics, when the corresponding Rust programs do not. dralley might even say that SIMD intrinsics have been available in Rust nightly for years. dralley might even say that someone has contributed a Rust program that does use SIMD intrinsics, but that program was slower than other Rust programs: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-rust-5.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Perhaps if C++ [or Rust] is providing SIMD intrinsics that is not in-itself a magical silver bullet.
ttul 8y ago
I read that book around 1998 and was an instant convert. C++ has a steep learning curve, and does not stop you from getting yourself into a lot of trouble, but it does stand up to Bjarne’s original promise about performance. IMHO the STL is one of mankind’s greatest accomplishments.
- jzwinck 8y ago
  The STL doesn't always live up to the standard of "zero overhead abstractions." The list is not high performance, many implementations of hash tables never shrink (and used to have O(n) erase!), and deque is a bad joke (no chunk size control, plus laughable fixed chunk size on some common platforms). Many high performance projects use vector but few other containers. If the STL had a lesson to teach us it should have been "iterators everywhere, including for your own algorithms and container types." Instead most people learned "C++ has all the containers you need built in, throw away your performance tricks and let it call malloc a million times."
  - jstimpfle 8y ago
    > Most high performance projects use vector and little else. Right. And then it is actually a lot simpler to simply use pointer + size pairs [1] instead of std::vector. Changing to explicit allocation was the best decision I've made. I now find myself not longing for any C++ features anymore at all. I haven't needed anything besides a little allocation wrapper [2] and maybe a string-to-hash map since. [1] Or n pointers + 1 size for parallel arrays, indicating that it's a bad idea to glue pointer + size in the first place. [2] https://gist.github.com/jstimpfle/562b2c3e9fe537e378351bb9d5be8cdb https://gist.github.com/jstimpfle/562b2c3e9fe537e378351bb9d5...
    - jstimpfle 8y ago
      > string-to-hash map string-to-int hash map
  - dralley 8y ago
    Endeavors that really need high performance tend to use other standard library implementations. I think EA has their own, for example.
krylon 8y ago
> The book "The Design and Evolution of C++" helps one understand why some things are the way they are and sometimes it helps understand why some things exist in the language in the first place. I am not a C++ programmer, but I found that book extremely interesting and a pleasure to read. I think I have publicly said so before, but I wish there were books like this for more programming languages. There's a couple of fascinating HOPL talks on languages like Lisp and Lua, but due to brevity, they are not nearly as detailed and in-depth as this one.
jchw 8y ago
If I had any real complaint about the execution of C++ it would probably just be the backwards compatibility with C. Don't get me wrong: I love C, and also I don't think it would've been possible for C++ to have gained so much relevance so fast had it not started as C with Classes. However, it does feel like a lot of kludges in C++ come from its legacy. Something that often confuses beginners is the sheer number of ways to do a thing, and some of them are not recommended to be used at all. With C diverging in incompatible ways from C++, the backwards compatibility has made less sense than ever.
- pjc50 8y ago
  If people wanted an object-orientated compiled language that didn't interlink with and offer a smooth transition from C, there were already alternatives (e.g. Modula).
  - jchw 8y ago
    The direction C++ went was pretty different from even what would've been considered 'object oriented' at the time. I'd say half of what made C++ special was how much stuff could happen purely at compile time.
- ben509 8y ago
  That's why the sheer insanity of Objective C++ intrigues me. I always speculated that Jobs went up to the engineers, "hey, we use a lot of Objective C in OS X, right?" "Yes, sir, Mr. Jobs." "Well, everyone else, namely Adobe, is using C++ and we need them writing apps for the Mac. We've gotta have those apps. So we're going to need to support that." "Um, yes sir, Mr. Jobs, we'll get right on that." He leaves, and they look around nervously. "He's pulling our leg, right?"
deleted 8y ago
[deleted]
corpMaverick 8y ago
I am not a C++ fan. But D&E of C++ is one the best books I ever read. It explains a lot of the real world of the decisions they had to make. It was iluminating.
stcredzero 8y ago
The book "The Design and Evolution of C++" helps one understand why some things are the way they are As I've said quite recently elsewhere, C++ is an archaeological dig of a language. There are something like 4 major strata. If you would learn and use C++, it behooves you to pick a particular style, then stick to that. (RAII and smart pointers are very useful!) There's something called the Taligent coding standards, which were once popular, then later castigated as turning C++ into "a poor man's Smalltalk." Small teams can write some dandy code using that style. Everything can fall apart at scale, however. (EDIT: Here's an example from elsewhere in these comments: https://news.ycombinator.com/item?id=17463569 https://news.ycombinator.com/item?id=17463569 )

Underqualified 8y ago

I always felt that if you wanted the same functionality as c++ in terms of performance, flexibility and power of abstraction, you'd end up with something as complex as c++. Modern c++ shows there was/is room for improvement, but it does not fundamentally simplify the language imo.

unrealhoang 8y ago
Only if it need to have backward compatibility. Rust doesn’t so it can be vastly simpler.
- okasaki 8y ago
  How is Rust simpler than C++?
  - virtualritz 8y ago
    Are you talking about grokking the language and its more excotic concepts or writing code on it? I have almost 30 years of C++ experience and about 6 months of Rust. My gut feeling is that the languages are equally difficult to understand but that the experience of writing code in them is very different. I'm sure Rust will have its own set of surprises as I keep using it. But I can't believe they will be nearly as bad as those that C++ comes with. ;)
  - smaddox 8y ago
    Rust is a much smaller language and stdlib than C++ (though still quite large). Rust makes an effort to make many things explicit that are implicit in C++, such as numeric type conversions. Rust's traits are conceptually simpler than classes, especially if you want multiple inheritance. Rust's templates/generics are much closer to the core language than C++'s template language. And then there are all of the safety features of Rust; while there is a learning curve, it is much easier to learn the concepts of lifetimes and ownership when the compiler is helping to enforce proper usage.
- deaddodo 8y ago
  I love Rust. Especially for emudev and embedded development (fields I would traditionally use C or C++). However, it still performs worse than C++ in most cases [1]. [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - dralley 8y ago
    A number of those C++ benchmarks are "cheating" by using SIMD intrinsics, which was only stabilized in Rust about two weeks ago.
    - igouy 8y ago
      1) Specifically which of those C++ programs? Innuendo is not OK. 2) Even with cheating in scare quotes, name-calling is not OK.
      - ben509 8y ago
        It's not innuendo when you consider the inherent problems with benchmarks. Once you have an algorithm, it's so hard to define what an objective benchmark is that you should assume the implementation is cheating, even if you wrote it. I say this from personal experience; in one case I was doing timing studies to solve performance problems, and wound up fooling myself by measuring the wrong thing! In this case, is it fair to use SIMD intrinsics? It depends on what you're trying to measure. I think that's why "cheating" is in scare quotes, because what would be cheating in one context might be useful information in another. For instance, if C++ is providing SIMD intrinsics, it's going to beat other languages, and if I just want current performance statistics, that's the question I want to answer. If the question is, "what's the overall quality of the code delivered by the compiler / optimizer" then using specific tricks doesn't give me a good answer.
        igouy 8y ago
        > …when you consider the inherent problems with benchmarks… dralley's comment does not do that. There's nothing difficult here: simply say that those X of N leading C++ programs use SIMD intrinsics, when the corresponding Rust programs do not. dralley might even say that SIMD intrinsics have been available in Rust nightly for years. dralley might even say that someone has contributed a Rust program that does use SIMD intrinsics, but that program was slower than other Rust programs: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-rust-5.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Perhaps if C++ [or Rust] is providing SIMD intrinsics that is not in-itself a magical silver bullet.

ttul 8y ago

I read that book around 1998 and was an instant convert. C++ has a steep learning curve, and does not stop you from getting yourself into a lot of trouble, but it does stand up to Bjarne’s original promise about performance. IMHO the STL is one of mankind’s greatest accomplishments.

jzwinck 8y ago
The STL doesn't always live up to the standard of "zero overhead abstractions." The list is not high performance, many implementations of hash tables never shrink (and used to have O(n) erase!), and deque is a bad joke (no chunk size control, plus laughable fixed chunk size on some common platforms). Many high performance projects use vector but few other containers. If the STL had a lesson to teach us it should have been "iterators everywhere, including for your own algorithms and container types." Instead most people learned "C++ has all the containers you need built in, throw away your performance tricks and let it call malloc a million times."
- jstimpfle 8y ago
  > Most high performance projects use vector and little else. Right. And then it is actually a lot simpler to simply use pointer + size pairs [1] instead of std::vector. Changing to explicit allocation was the best decision I've made. I now find myself not longing for any C++ features anymore at all. I haven't needed anything besides a little allocation wrapper [2] and maybe a string-to-hash map since. [1] Or n pointers + 1 size for parallel arrays, indicating that it's a bad idea to glue pointer + size in the first place. [2] https://gist.github.com/jstimpfle/562b2c3e9fe537e378351bb9d5be8cdb https://gist.github.com/jstimpfle/562b2c3e9fe537e378351bb9d5...
  - jstimpfle 8y ago
    > string-to-hash map string-to-int hash map
- dralley 8y ago
  Endeavors that really need high performance tend to use other standard library implementations. I think EA has their own, for example.

krylon 8y ago

> The book "The Design and Evolution of C++" helps one understand why some things are the way they are and sometimes it helps understand why some things exist in the language in the first place. I am not a C++ programmer, but I found that book extremely interesting and a pleasure to read. I think I have publicly said so before, but I wish there were books like this for more programming languages. There's a couple of fascinating HOPL talks on languages like Lisp and Lua, but due to brevity, they are not nearly as detailed and in-depth as this one.

jchw 8y ago

If I had any real complaint about the execution of C++ it would probably just be the backwards compatibility with C. Don't get me wrong: I love C, and also I don't think it would've been possible for C++ to have gained so much relevance so fast had it not started as C with Classes. However, it does feel like a lot of kludges in C++ come from its legacy. Something that often confuses beginners is the sheer number of ways to do a thing, and some of them are not recommended to be used at all. With C diverging in incompatible ways from C++, the backwards compatibility has made less sense than ever.

pjc50 8y ago
If people wanted an object-orientated compiled language that didn't interlink with and offer a smooth transition from C, there were already alternatives (e.g. Modula).
- jchw 8y ago
  The direction C++ went was pretty different from even what would've been considered 'object oriented' at the time. I'd say half of what made C++ special was how much stuff could happen purely at compile time.
ben509 8y ago
That's why the sheer insanity of Objective C++ intrigues me. I always speculated that Jobs went up to the engineers, "hey, we use a lot of Objective C in OS X, right?" "Yes, sir, Mr. Jobs." "Well, everyone else, namely Adobe, is using C++ and we need them writing apps for the Mac. We've gotta have those apps. So we're going to need to support that." "Um, yes sir, Mr. Jobs, we'll get right on that." He leaves, and they look around nervously. "He's pulling our leg, right?"

deleted 8y ago

[deleted]

corpMaverick 8y ago

I am not a C++ fan. But D&E of C++ is one the best books I ever read. It explains a lot of the real world of the decisions they had to make. It was iluminating.

stcredzero 8y ago

The book "The Design and Evolution of C++" helps one understand why some things are the way they are As I've said quite recently elsewhere, C++ is an archaeological dig of a language. There are something like 4 major strata. If you would learn and use C++, it behooves you to pick a particular style, then stick to that. (RAII and smart pointers are very useful!) There's something called the Taligent coding standards, which were once popular, then later castigated as turning C++ into "a poor man's Smalltalk." Small teams can write some dandy code using that style. Everything can fall apart at scale, however. (EDIT: Here's an example from elsewhere in these comments: https://news.ycombinator.com/item?id=17463569 https://news.ycombinator.com/item?id=17463569 )