3 ms·

He basically added every feature he could think of on top of C, glued it with spit and released it as a pre-processor. There was barely any design involved. Jus

He basically added every feature he could think of on top of C, glued it with spit and released it as a pre-processor. There was barely any design involved. Just look at how many types of inheritance there are. I remember Stanley B. Lippman (one of the first developers on cfront) recollecting how the proposal to implement multiple inheritance was met with resistance from the community. And the implementing team realized they couldn't write a sane implementation, and people complained against it, but they made one anyway, partially because they wanted to prove they could. New features to cfront were added with very little concern for design. Things where standardization would have mattered (like the mangling algorithm) were never touched, so now every compiler has the liberty to generate whatever symbols it wants, and call functions with whatever calling convention it chooses, so you either have to compile all your dependencies, or make sure you fetch the binaries that use the exact same compiler version and flags, otherwise they won't link. Also, Stroustrup didn't "soldier on", the CPP standard is maintained by a committee of people from all over the world, and the standard library slowly adopts data types and algorithms from the boost library, because they need a multi-year staging period, handled by someone else, to see if things work before they muster the courage to standardize it.

pjmlp 5y ago
The reasoning behind what was added is clearly described in the "Design and Evolution of C++" book. Besides the main reason why C++ exists is because he swore to himself never to go through the Simula => BCPL downgrade ever again, and C is a tiny step up from Bootstraping CPL compiler, so....
- rootlocus 5y ago
  Here are a few excerpts from "The Design and Evolution of C++" Another factor was purely irrational. Nobody seemed to doubt that I could implement templates efficiently. Multiple inheritance, on the other hand, was widely supposed to be very difficult to implement efficiently. For example, in summary of C++ in his book on Objective C, Brad Cox actually claimed that adding multiple inheritance to C++ was impossible. Thus, multiple inheritance seemed more of a challenge. He then goes on a 13 page explanation of how he thought there was a simple implementation. He then acknowledges the controversy, but brushes it aside with: I think - as I did then - that the fundamental flaw in these arguments is that they take multiple inheritance far too seriously. Multiple inheritance doesn't solve all your problems, but it doesn't need to because it's quite cheap. Sometimes multiple inheritance is very convenient to have. I have kept out of the multiple inheritance debates: multiple inheritance is in C++ and cannot be taken out or radically changed; I personally find multiple inheritance useful at times; some people insist that multiple inheritance is essential to their approach to design and implementation; it is still to early to have solid data and experience about the value of C++ multiple inheritance in large scale use; and, finally, I don't like to spend my time on sterile discussions. This goes hand in hand with the original "principles" of C++ design, namely "C++ must be useful now". It didn't really matter how the complexity will evolve in the future, as long as it solved someone's problem today. And once it was implemented, there was no going back, so it didn't matter what people thought, it was done. This process isn't really what I would call "design".
  - pjmlp 5y ago
    So what would you call "design", the ups and downs of C married with UNIX porting from PDP-7 into PDP-11, or a waterfall design Algol-68 style?
    - rootlocus 5y ago
      Rob Pike's reluctance to implement anything in Go that would add unnecessary complexity. Or Andrew Kelley's Zig language principles of no hidden control flow. These are examples of doing more with less and avoiding unnecessary complexity by thinking ahead. Ironically, they probably wouldn't be designed the way they are if it wasn't for the hindsight provided by C++
      - pjmlp 5y ago
        Ah that is why Go has such a great design for generics, and Zig already has the ideal solution for use-after-free errors, got it.
        rootlocus 5y ago
        People still write Go applications fine without generics, and Zig is a smidge higher level than C and currently in beta. How does this disprove anything I argued before?
        pjmlp 5y ago
        Ah, so now the argument moved from how delightful the authors of those languages are capable to perfectly design them, to people write code in them, got it.
        rootlocus 5y ago
        It's really ironic that you're the one to play the goal post moving card, when you haven't refuted my original statement. They don't have to be "perfectly" designed, the design needs to exist. If Go didn't have a design, it would've had a half assed generics implementation, like C++ has multiple inheritance. It's precisely because generics are hard to implement right and the design constrains how much you can stretch the language that Go still doesn't have them. And it's arguably a good thing. Sorry I wasn't explicit: it's safer and easier to write the same application in Go or Zig than it is in C++, even without generics or read-after-write compile-time checks.
KptMarchewa 5y ago
Or, how much ways is there to initialize a variable: https://mikelui.io/2019/01/03/seriously-bonkers.html https://mikelui.io/2019/01/03/seriously-bonkers.html

pjmlp 5y ago

The reasoning behind what was added is clearly described in the "Design and Evolution of C++" book. Besides the main reason why C++ exists is because he swore to himself never to go through the Simula => BCPL downgrade ever again, and C is a tiny step up from Bootstraping CPL compiler, so....

rootlocus 5y ago
Here are a few excerpts from "The Design and Evolution of C++" Another factor was purely irrational. Nobody seemed to doubt that I could implement templates efficiently. Multiple inheritance, on the other hand, was widely supposed to be very difficult to implement efficiently. For example, in summary of C++ in his book on Objective C, Brad Cox actually claimed that adding multiple inheritance to C++ was impossible. Thus, multiple inheritance seemed more of a challenge. He then goes on a 13 page explanation of how he thought there was a simple implementation. He then acknowledges the controversy, but brushes it aside with: I think - as I did then - that the fundamental flaw in these arguments is that they take multiple inheritance far too seriously. Multiple inheritance doesn't solve all your problems, but it doesn't need to because it's quite cheap. Sometimes multiple inheritance is very convenient to have. I have kept out of the multiple inheritance debates: multiple inheritance is in C++ and cannot be taken out or radically changed; I personally find multiple inheritance useful at times; some people insist that multiple inheritance is essential to their approach to design and implementation; it is still to early to have solid data and experience about the value of C++ multiple inheritance in large scale use; and, finally, I don't like to spend my time on sterile discussions. This goes hand in hand with the original "principles" of C++ design, namely "C++ must be useful now". It didn't really matter how the complexity will evolve in the future, as long as it solved someone's problem today. And once it was implemented, there was no going back, so it didn't matter what people thought, it was done. This process isn't really what I would call "design".
- pjmlp 5y ago
  So what would you call "design", the ups and downs of C married with UNIX porting from PDP-7 into PDP-11, or a waterfall design Algol-68 style?
  - rootlocus 5y ago
    Rob Pike's reluctance to implement anything in Go that would add unnecessary complexity. Or Andrew Kelley's Zig language principles of no hidden control flow. These are examples of doing more with less and avoiding unnecessary complexity by thinking ahead. Ironically, they probably wouldn't be designed the way they are if it wasn't for the hindsight provided by C++
    - pjmlp 5y ago
      Ah that is why Go has such a great design for generics, and Zig already has the ideal solution for use-after-free errors, got it.
      - rootlocus 5y ago
        People still write Go applications fine without generics, and Zig is a smidge higher level than C and currently in beta. How does this disprove anything I argued before?
        pjmlp 5y ago
        Ah, so now the argument moved from how delightful the authors of those languages are capable to perfectly design them, to people write code in them, got it.
        rootlocus 5y ago
        It's really ironic that you're the one to play the goal post moving card, when you haven't refuted my original statement. They don't have to be "perfectly" designed, the design needs to exist. If Go didn't have a design, it would've had a half assed generics implementation, like C++ has multiple inheritance. It's precisely because generics are hard to implement right and the design constrains how much you can stretch the language that Go still doesn't have them. And it's arguably a good thing. Sorry I wasn't explicit: it's safer and easier to write the same application in Go or Zig than it is in C++, even without generics or read-after-write compile-time checks.

KptMarchewa 5y ago

Or, how much ways is there to initialize a variable: https://mikelui.io/2019/01/03/seriously-bonkers.html https://mikelui.io/2019/01/03/seriously-bonkers.html