5 ms·

This shouldn't be downvoted. C++ is a superset of C; it must be capable of being at least as "brutal and honest" and "abstract and deceiving" as C. I would arg

This shouldn't be downvoted. C++ is a superset of C; it must be capable of being at least as "brutal and honest" and "abstract and deceiving" as C. I would argue that C++ can be dramatically more deceiving than C --- see inheritance and operator overloading, just to name two.

AlexeyBrin 4y ago
C++ is not a superset of C, there are plenty of legal C constructs that will trigger errors when compiled with a C++ compiler.
- wiseowise 4y ago
  C++ is a sane defaults superset of C.
- 3836293648 4y ago
  C is not a superset of C either. C++ is a superset of a C version, even if they then went on to add stuff that wasn't added to the other
- kazinator 4y ago
  But most of them are new constructs, not found in the venerable C90.
Koshkin 4y ago
Operator overloading is the one thing that makes C++ strictly better than any language that does not allow it.
- camel-cdr 4y ago
  How so? To me, operator overloading seems like a non feature, that at best create more ambiguity.
  - Conscat 4y ago
    Without it, you cannot express arithmetic wrappers or simd wrappers. So far, no language with any users has managed to provide adequate arithmetic and simd types built in, despite several attempts like Odin and CosmiC/HolyC. I'm not sure it's even possible to design such types that satisfy everyone, and they must be extensible somehow because satisfying anyone is a moving target. Note how terrible doing any amount of math is in C.
    - menaerus 4y ago
      Also without operator overloading, it wouldn't be possible to implement lazy evaluation, which along with the use of expression templates happens to be one of the most crucial aspects that any linear algebra library will want to take advantage of in order to generate the most optimal code.
      - Someone 4y ago
        > without operator overloading, it wouldn't be possible to implement lazy evaluation I don’t understand that. You can have functions that return promises that then can get passed to other functions returning promises, and leave it either to the compiler or to an expression evaluator you write (that ideally runs at compilation time as much as possible) to optimize away anything not needed. For example (pseudo-code) vector3D a = … vector3D b = … promise<vector3D> c = addLazily(a,b) print c.x in the end, could do the equivalent of print a.x + b.x I think you could make a modern C++ compiler do that for this simple example.
        menaerus 4y ago
        Of course, you can do it that way as well. However the problem with promise approach is that it is introducing extra dynamic memory allocations beneath and these cannot be optimized out or elided. At least, not to my knowledge. With expression templates and operator overloading you're basically avoiding exactly that as much as possible.
- tialaramex 4y ago
  Overloading is miserable. C++ has to provide this as an overload because it still, decades after standardisation and half a lifetime after it was created, doesn't have a way to just extend types. If you can just extend the types then you can provide operators that way and there's less opportunity for ambiguity. See Rust. Also so many of the C++ operator overloads are broken instead of just not existing, which tempts you to overload things instead of saying "Nope, that's a bad idea" and just walking away altogether. Example, boolean short-circuiting AND and OR. If we write if (this() || that()) foo(); in C++ then that OR is short-circuiting, so that() won't get called if this() is true. But if the return type used overloads the boolean OR operator, short-circuiting is disabled, and now both this() and that() are always called...

AlexeyBrin 4y ago

C++ is not a superset of C, there are plenty of legal C constructs that will trigger errors when compiled with a C++ compiler.

wiseowise 4y ago
C++ is a sane defaults superset of C.
3836293648 4y ago
C is not a superset of C either. C++ is a superset of a C version, even if they then went on to add stuff that wasn't added to the other
kazinator 4y ago
But most of them are new constructs, not found in the venerable C90.

Koshkin 4y ago

Operator overloading is the one thing that makes C++ strictly better than any language that does not allow it.

camel-cdr 4y ago
How so? To me, operator overloading seems like a non feature, that at best create more ambiguity.
- Conscat 4y ago
  Without it, you cannot express arithmetic wrappers or simd wrappers. So far, no language with any users has managed to provide adequate arithmetic and simd types built in, despite several attempts like Odin and CosmiC/HolyC. I'm not sure it's even possible to design such types that satisfy everyone, and they must be extensible somehow because satisfying anyone is a moving target. Note how terrible doing any amount of math is in C.
  - menaerus 4y ago
    Also without operator overloading, it wouldn't be possible to implement lazy evaluation, which along with the use of expression templates happens to be one of the most crucial aspects that any linear algebra library will want to take advantage of in order to generate the most optimal code.
    - Someone 4y ago
      > without operator overloading, it wouldn't be possible to implement lazy evaluation I don’t understand that. You can have functions that return promises that then can get passed to other functions returning promises, and leave it either to the compiler or to an expression evaluator you write (that ideally runs at compilation time as much as possible) to optimize away anything not needed. For example (pseudo-code) vector3D a = … vector3D b = … promise<vector3D> c = addLazily(a,b) print c.x in the end, could do the equivalent of print a.x + b.x I think you could make a modern C++ compiler do that for this simple example.
      - menaerus 4y ago
        Of course, you can do it that way as well. However the problem with promise approach is that it is introducing extra dynamic memory allocations beneath and these cannot be optimized out or elided. At least, not to my knowledge. With expression templates and operator overloading you're basically avoiding exactly that as much as possible.
tialaramex 4y ago
Overloading is miserable. C++ has to provide this as an overload because it still, decades after standardisation and half a lifetime after it was created, doesn't have a way to just extend types. If you can just extend the types then you can provide operators that way and there's less opportunity for ambiguity. See Rust. Also so many of the C++ operator overloads are broken instead of just not existing, which tempts you to overload things instead of saying "Nope, that's a bad idea" and just walking away altogether. Example, boolean short-circuiting AND and OR. If we write if (this() || that()) foo(); in C++ then that OR is short-circuiting, so that() won't get called if this() is true. But if the return type used overloads the boolean OR operator, short-circuiting is disabled, and now both this() and that() are always called...