4 ms·

My experience of the language has been similar, including the bit about it no longer being part of my life. For a long time, the complaint was that it was bein

My experience of the language has been similar, including the bit about it no longer being part of my life. For a long time, the complaint was that it was being used as nothing more than a "better C", though in my experience, the worst abuses came from among those who were determined to use every feature. In the beginning, the fact that early C++ was a superset of C is probably what led to its widespread adoption, but the legacy of that decision, particularly with regard to pointers and pointer arithmetic, has been a multiplier of complexity.

squidgyhead 3y ago
Sometimes pointer arithmetic is the best implementation; are you implying that C++ would be better off without access to this feature?
- WalterBright 3y ago
  The D language dynamic array, which is a pointer+length pair, has (over time) nearly completely supplanted pointer arithmetic. The pair prevents buffer overflows and underflows. Raw pointer arithmetic is not allowed in code marked @safe. I've proposed it for C and C++: https://www.digitalmars.com/articles/C-biggest-mistake.html https://www.digitalmars.com/articles/C-biggest-mistake.html It would be simple to add it, and would be legacy compatible.
- angiosperm 3y ago
  I very rarely find a use for pointers anymore. Often a whole program has none at all, not even unique_ptr<>. When I do use them, they are front-and-center enough to make mistakes unlikely.
  - blt 3y ago
    I also rarely use them, but sometimes pointers (via virtual methods and factories) can reduce compile times a lot for components with a stable API but high complexity and churn of the internals. Do you have another way to handle that?
    - angiosperm 3y ago
      I tend to rely on member unique_ptr for such concerns. At top level, you still don't see any pointers. Of course at machine level the code is absolutely lousy with pointers, likewise at the next level up, but the pointers you can't see because they are buried in libraries cannot generate bugs.
- mannykannot 3y ago
  I surmised it would be less complex.

squidgyhead 3y ago

Sometimes pointer arithmetic is the best implementation; are you implying that C++ would be better off without access to this feature?

WalterBright 3y ago
The D language dynamic array, which is a pointer+length pair, has (over time) nearly completely supplanted pointer arithmetic. The pair prevents buffer overflows and underflows. Raw pointer arithmetic is not allowed in code marked @safe. I've proposed it for C and C++: https://www.digitalmars.com/articles/C-biggest-mistake.html https://www.digitalmars.com/articles/C-biggest-mistake.html It would be simple to add it, and would be legacy compatible.
angiosperm 3y ago
I very rarely find a use for pointers anymore. Often a whole program has none at all, not even unique_ptr<>. When I do use them, they are front-and-center enough to make mistakes unlikely.
- blt 3y ago
  I also rarely use them, but sometimes pointers (via virtual methods and factories) can reduce compile times a lot for components with a stable API but high complexity and churn of the internals. Do you have another way to handle that?
  - angiosperm 3y ago
    I tend to rely on member unique_ptr for such concerns. At top level, you still don't see any pointers. Of course at machine level the code is absolutely lousy with pointers, likewise at the next level up, but the pointers you can't see because they are buried in libraries cannot generate bugs.
mannykannot 3y ago
I surmised it would be less complex.