4 ms·

C++ is not "letting the programmer fully control every knob". Quite the opposite. Buggy, insecure, broken software is usually not the intention. The developer w

by 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.
        pjmlp 8y ago
        In Modula-3 and other safe systems programming languages all the way back to NEWP in the 60's, something like UNSAFE MODULE is exposed in the type system, whereas in C and C++ you have no idea what a library might do. And in C all bets are open.
      - keldaris 8y ago
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.

by dpc_pw 8y ago

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.
      - pjmlp 8y ago
        In Modula-3 and other safe systems programming languages all the way back to NEWP in the 60's, something like UNSAFE MODULE is exposed in the type system, whereas in C and C++ you have no idea what a library might do. And in C all bets are open.
    - keldaris 8y ago

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.