3 ms·

>> While there might be 30+ years of divergence between C and C++, none of C++’s so-called “progress” involved removing memory-unsafe C features from C++, many

by mbfg 4y ago

>> While there might be 30+ years of divergence between C and C++, none of C++’s so-called “progress” involved removing memory-unsafe C features from C++, many of which are still in common use, and many of which still make memory safety in C++ near intractible I think just the concept of classes, and new, help with memory safety. It's harder to screw with memory with new Foo() then doing a malloc and memcpying bits into a buffer. Sure it's far cry from real memory safety, but i do think c++ has a bunch of improvements over c in memory safety. Sure you can do all the nasty bits in c++ that you could do in c, but you are carrotted out of doing them most of the time.

olliej 4y ago
Alas it doesn’t really help - new is just as bad as malloc, and the fact that there is no difference syntactically or in the type system between a pointer to an object and a pointer to an array means that c++s new introduces the joy of calling the wrong delete \o/
- david2ndaccount 4y ago
  This is incorrect, but most C and C++ programmers would be stumped by `int(*y)[3]` (which is how you spell a pointer to an array of length 3).
  - pjmlp 4y ago
    Plenty of C++ developers still mix up delete versus delete[].
    - olliej 4y ago
      Which is my point: the type system doesn't distinguish T* (a single object) T* (an array of objects), so delete vs delete[] only shows up as runtime heap corruption that may or may not eagerly terminate or lead to RCE.
  - olliej 4y ago
    The type of `new T[N]` is T. The type of `new T[10]` is also T. The type of `new T` is also T. Yes if you have a statically sized array you can make a pointer to an array of that length, but those are generally not relevant outside of specific cases (arrays in structs or on the stack where the size impacts offsets in codegen). More over the desire of C and C++ to drop those annotations is such that even using your proposal of a pointer to an array rather than just an array, is of questionable value. Take an extension of your example: int(*y)[3] = ...; int(*y2)[3] = ...; You can't do *y2 = *y; Because C doesn't let you assign arrays by value, even fixed size ones \o/

by mbfg 4y ago

olliej 4y ago

Alas it doesn’t really help - new is just as bad as malloc, and the fact that there is no difference syntactically or in the type system between a pointer to an object and a pointer to an array means that c++s new introduces the joy of calling the wrong delete \o/

david2ndaccount 4y ago
This is incorrect, but most C and C++ programmers would be stumped by `int(*y)[3]` (which is how you spell a pointer to an array of length 3).
- pjmlp 4y ago
  Plenty of C++ developers still mix up delete versus delete[].
  - olliej 4y ago
    Which is my point: the type system doesn't distinguish T* (a single object) T* (an array of objects), so delete vs delete[] only shows up as runtime heap corruption that may or may not eagerly terminate or lead to RCE.
- olliej 4y ago
  The type of `new T[N]` is T. The type of `new T[10]` is also T. The type of `new T` is also T. Yes if you have a statically sized array you can make a pointer to an array of that length, but those are generally not relevant outside of specific cases (arrays in structs or on the stack where the size impacts offsets in codegen). More over the desire of C and C++ to drop those annotations is such that even using your proposal of a pointer to an array rather than just an array, is of questionable value. Take an extension of your example: int(*y)[3] = ...; int(*y2)[3] = ...; You can't do *y2 = *y; Because C doesn't let you assign arrays by value, even fixed size ones \o/