6 ms·

Exactly. It's become fashionable to decry the lengths to which C/C++ compilers are able to go in the pursuit of performance because of "safety" issues, but the

Exactly. It's become fashionable to decry the lengths to which C/C++ compilers are able to go in the pursuit of performance because of "safety" issues, but the advantage of letting the programmer fully control every knob in the chain is immense.

pjmlp 8y ago
With great power comes great responsibility. I might not code daily in C++ anymore, but it would be nice that the software I rely on, specially in devices I am not able to upgrade, wouldn't suffer from such issues. Butcher knifes are deadly sharp, yet those conscious ones do use proper gloves when handling them.
dpc_pw 8y ago
C++ is not "letting the programmer fully control every knob". Quite the opposite. Buggy, insecure, broken software is usually not the intention. The developer wanted one thing, and got something else, because of arcane details of the language. C++ is just a bad programming language, and "but it's powerful" is not invalidating that fact.
- keldaris 8y ago
  I certainly wouldn't call C++ a good programming language (rather, I would call it the only viable option for most of its usecases, badly designed though it is). However, I will stick by the "letting the programmer fully control every knob" phrase I used. I never claimed it makes it easy and you can make a lot of good arguments regarding better defaults, but it absolutely eschews restricting programmer freedom, at a not inconsiderable price.
  - pjmlp 8y ago
    Ada and Modula-3 are two examples of languages that also let the programmers control every knob, when needed, without exposing the traditional unsafety issues that C++ has inherited from C. But alas, one was too expensive to become mainstream and the other died when Compaq acquired DEC.
    - keldaris 8y ago
      I don't know enough about optimizing Ada code to comment competently on your assertion, but part of the reason it's very hard to compete with C/C++ is simply because of the immense effort that's gone into improving the compilers. These days the only languages that are remotely comparable to C/C++ in terms of performance directly benefit from that effort - they either use the LLVM (Rust, Julia, the LDC compiler for D, etc.) or transpile to C (like Nim). The only real differentiation comes from the semantics they expose and any additional machinery they offer on top of that stack (like the Julia JIT).
      - pjmlp 8y ago
        In terms of language features they are safe by default, but do provide enough escape hatch to make it as unsafe as C and C++. The big difference is that you as developer will notice that you are doing something that might eventually blow up, because it is very explicit. For example something like doing a reinterpret_cast would be LOOPHOLE call in Modula-3 and is only allowed inside an UNSAFE MODULE implementation. As for the rest, yes C and C++ have enjoyed 30 years of compiler research, but as Fran Allen puts it, C has brought compiler optimization research back to the pre-history. If you read IBM's research papers on PL.8, the systems programming language used on the RISC project, it already had an architecture similar to what LLVM has. Where the multiple compiler phases were taking care of the optimizations. Then when they decided to go commercial, they rather adopted UNIX as platform. So maybe we would be somewhere else had AT&T been allowed to sell UNIX at the same price as VMS, z/OS and others. As for the LLVM, we aren't going to throw that code away, but as you also assert, it is possible to use safer languages while taking advantage of the optimization work that went into LLVM. That is how I see C and C++'s future, down into a thin infrastructure layer, with userspace mostly written in something else.
        zlynx 8y ago
        reinterpret_cast in C++ should be read by the programmer as "UNSAFE CODE HERE!!!" It is prone to aliasing issues and all kinds of other problems. In C code, any cast at all, of any kind, should be viewed with the utmost suspicion. That's why unions have been chosen as the correct way to alias pointers. Because it is unlikely that a programmer accidentally used the wrong type or that code changes made a type cast obsolete.
- coliveira 8y ago
  The reason C++ is badly designed is exactly to let programmers control how it operates. I don't subscribe to the philosophy, but I understand it. Trying to denigrate the language because of these choices is, in my view, absurd.
  - WalterBright 8y ago
    > The reason C++ is badly designed is exactly to let programmers control how it operates. The reason is backwards compatibility. C++ has a long history, and mistakes were made in the past including mistakes carried over from C: https://www.digitalmars.com/articles/b44.html https://www.digitalmars.com/articles/b44.html and C++ tries to fold improvements in without breaking compatibility.
vvanders 8y ago
> but the advantage of letting the programmer fully control every knob in the chain is immense. That's actually not completely true. Take the restrict keyword for instance. Super painful to use in C/C++ and very dangerous. In Rust since the language has constrains around single mutable pointers they can turn it on globally and you get it "for free". If I recall correctly it's going live in one of the upcoming stable releases. Sometimes constraints can actually let you get better performance than a wild-west of pointers everywhere.
- shepmaster 8y ago
  > going live in one of the upcoming stable releases If I remember correctly, it was originally enabled but had to be disabled because LLVM had some bugs around how it was handled. These arose because `restrict` is comparatively rarely used in C / C++ code. https://github.com/rust-lang/rust/issues/31681 https://github.com/rust-lang/rust/issues/31681
  - steveklabnik 8y ago
    Turning it back on landed in master a little over a month ago; meaning it will be in Rust 1.28, the next release.
- keldaris 8y ago
  Of all the sharp tools in C, restrict is one of the last things I'd call dangerous (restrict is not a standard keyword in C++, by the way, although most compilers support it as an extension). It's completely opt-in, relatively rarely used, and to even think of using it you have to be already thinking about aliasing issues. If you write a function using restrict and suddenly completely change your intent mid way, I really don't think that's a language design issue. Of course it's still a sharp tool and explicitly meant as such - as a last resort for cases where you can't rely on the compiler to infer the right thing on its own.
  - vvanders 8y ago
    Sure but my point wasn't about the ergonomics of restrict, more that having a wild-west of pointers means that some performance optimizations are now off the table vs languages that are a bit more constrained in how they approach data access patterns.

pjmlp 8y ago

With great power comes great responsibility. I might not code daily in C++ anymore, but it would be nice that the software I rely on, specially in devices I am not able to upgrade, wouldn't suffer from such issues. Butcher knifes are deadly sharp, yet those conscious ones do use proper gloves when handling them.

dpc_pw 8y ago

C++ is not "letting the programmer fully control every knob". Quite the opposite. Buggy, insecure, broken software is usually not the intention. The developer wanted one thing, and got something else, because of arcane details of the language. C++ is just a bad programming language, and "but it's powerful" is not invalidating that fact.

keldaris 8y ago
I certainly wouldn't call C++ a good programming language (rather, I would call it the only viable option for most of its usecases, badly designed though it is). However, I will stick by the "letting the programmer fully control every knob" phrase I used. I never claimed it makes it easy and you can make a lot of good arguments regarding better defaults, but it absolutely eschews restricting programmer freedom, at a not inconsiderable price.
- pjmlp 8y ago
  Ada and Modula-3 are two examples of languages that also let the programmers control every knob, when needed, without exposing the traditional unsafety issues that C++ has inherited from C. But alas, one was too expensive to become mainstream and the other died when Compaq acquired DEC.
  - keldaris 8y ago
    I don't know enough about optimizing Ada code to comment competently on your assertion, but part of the reason it's very hard to compete with C/C++ is simply because of the immense effort that's gone into improving the compilers. These days the only languages that are remotely comparable to C/C++ in terms of performance directly benefit from that effort - they either use the LLVM (Rust, Julia, the LDC compiler for D, etc.) or transpile to C (like Nim). The only real differentiation comes from the semantics they expose and any additional machinery they offer on top of that stack (like the Julia JIT).
    - pjmlp 8y ago
      In terms of language features they are safe by default, but do provide enough escape hatch to make it as unsafe as C and C++. The big difference is that you as developer will notice that you are doing something that might eventually blow up, because it is very explicit. For example something like doing a reinterpret_cast would be LOOPHOLE call in Modula-3 and is only allowed inside an UNSAFE MODULE implementation. As for the rest, yes C and C++ have enjoyed 30 years of compiler research, but as Fran Allen puts it, C has brought compiler optimization research back to the pre-history. If you read IBM's research papers on PL.8, the systems programming language used on the RISC project, it already had an architecture similar to what LLVM has. Where the multiple compiler phases were taking care of the optimizations. Then when they decided to go commercial, they rather adopted UNIX as platform. So maybe we would be somewhere else had AT&T been allowed to sell UNIX at the same price as VMS, z/OS and others. As for the LLVM, we aren't going to throw that code away, but as you also assert, it is possible to use safer languages while taking advantage of the optimization work that went into LLVM. That is how I see C and C++'s future, down into a thin infrastructure layer, with userspace mostly written in something else.
      - zlynx 8y ago
        reinterpret_cast in C++ should be read by the programmer as "UNSAFE CODE HERE!!!" It is prone to aliasing issues and all kinds of other problems. In C code, any cast at all, of any kind, should be viewed with the utmost suspicion. That's why unions have been chosen as the correct way to alias pointers. Because it is unlikely that a programmer accidentally used the wrong type or that code changes made a type cast obsolete.
coliveira 8y ago
The reason C++ is badly designed is exactly to let programmers control how it operates. I don't subscribe to the philosophy, but I understand it. Trying to denigrate the language because of these choices is, in my view, absurd.
- WalterBright 8y ago
  > The reason C++ is badly designed is exactly to let programmers control how it operates. The reason is backwards compatibility. C++ has a long history, and mistakes were made in the past including mistakes carried over from C: https://www.digitalmars.com/articles/b44.html https://www.digitalmars.com/articles/b44.html and C++ tries to fold improvements in without breaking compatibility.

vvanders 8y ago

> but the advantage of letting the programmer fully control every knob in the chain is immense. That's actually not completely true. Take the restrict keyword for instance. Super painful to use in C/C++ and very dangerous. In Rust since the language has constrains around single mutable pointers they can turn it on globally and you get it "for free". If I recall correctly it's going live in one of the upcoming stable releases. Sometimes constraints can actually let you get better performance than a wild-west of pointers everywhere.

shepmaster 8y ago
> going live in one of the upcoming stable releases If I remember correctly, it was originally enabled but had to be disabled because LLVM had some bugs around how it was handled. These arose because `restrict` is comparatively rarely used in C / C++ code. https://github.com/rust-lang/rust/issues/31681 https://github.com/rust-lang/rust/issues/31681
- steveklabnik 8y ago
  Turning it back on landed in master a little over a month ago; meaning it will be in Rust 1.28, the next release.
keldaris 8y ago
Of all the sharp tools in C, restrict is one of the last things I'd call dangerous (restrict is not a standard keyword in C++, by the way, although most compilers support it as an extension). It's completely opt-in, relatively rarely used, and to even think of using it you have to be already thinking about aliasing issues. If you write a function using restrict and suddenly completely change your intent mid way, I really don't think that's a language design issue. Of course it's still a sharp tool and explicitly meant as such - as a last resort for cases where you can't rely on the compiler to infer the right thing on its own.
- vvanders 8y ago
  Sure but my point wasn't about the ergonomics of restrict, more that having a wild-west of pointers means that some performance optimizations are now off the table vs languages that are a bit more constrained in how they approach data access patterns.