3 ms·

There is no such language as "C/C++". Using the expression reveals tendentious bias. Those of us using modern C++ do not ship memory usage faults, and have not

There is no such language as "C/C++". Using the expression reveals tendentious bias. Those of us using modern C++ do not ship memory usage faults, and have not done for years. So, experience with C and pre-modern C++ does not generalize.

throw10920 4y ago
Do popular compilers ship with an option that forbids the use of all memory-unsafe constructs? If not, then "modern C++" is still not memory-safe.
- pencilguin 4y ago
  Where there is no need for any unsafe construct, code that therefore does not use them is safe. The same applies to, e.g., Rust: any Rust program may use unsafe blocks. That Rust programs may contain unsafe blocks does not make Rust implicitly unsafe. Even using unsafe blocks does not, by itself, make the program unsafe.
  - throw10920 4y ago
    Your dodging of my question leads me to believe that the answer is "no". Therefore, "modern C++" is still unsafe. > Even using unsafe blocks does not, by itself, make the program unsafe. This is false. "Unsafe" means that there is the potential to cause memory safety bugs. Unsafe blocks and C++ cause this, by definition. "Unsafe" does not mean that a memory safety bug actually exists. Moreover, I didn't mention anything about Rust in my comment.
guhidalg 4y ago
Pedantic clarity isn't helping your argument. The fact that you can choose to write C while calling a C++ compiler means people will always call it C/C++.
- pencilguin 4y ago
  It means that conclusions based on pretending it is a meaningful expression are tainted at the source, and thus may be presumed invalid without further examination. If you are coding C or pre-modern C++, then you are not coding modern C++, regardless of the compiler you happen to build with.
  - sitkack 4y ago
    Your parent comment is an example Not True Scotsman [1] and circular logic. Your claim that modern C++ doesn't ship memory safety issues is a fallacy not worth my time for a rebuttal. https://en.wikipedia.org/wiki/No_true_Scotsman https://en.wikipedia.org/wiki/No_true_Scotsman
    - pencilguin 4y ago
      C++20 is an International Standard, superseding all previous Standards. Programs that use C++20 constructs in preference to pre-C++11 constructs are objectively more modern, to the exact degree they do.
      - samatman 4y ago
        Your position could be taken seriously if, and only if, there were a version of the language which doesn't contain all the cruft. As in, there are compilers which won't compile it. Instead, mid-90s C++, with all the leaks, is valid C++, 20 or otherwise. No true C++20 program is memory unsafe... unless you use a normal pointer, which is always available and will bork you just as hard as in C.
        pencilguin 4y ago
        Where there is no need for a native pointer to be used, as almost everywhere, and no pointer is used, that code is objectively more modern than code that uses the pointer anyway. It is very rare to need to use a native pointer in modern C++ code. The need for one is strictly less common than a need for an unsafe block in Rust. Your argument applies equally well to Rust: any Rust program may include unsafe blocks. That any program may contain unsafe blocks does not make Rust implicitly unsafe. That a Rust program does (transitively) contain unsafe blocks does not make it an unsafe program. All substantial Rust programs at least transitively contain unsafe blocks. Thus, your argument is invalid.

throw10920 4y ago

Do popular compilers ship with an option that forbids the use of all memory-unsafe constructs? If not, then "modern C++" is still not memory-safe.

pencilguin 4y ago
Where there is no need for any unsafe construct, code that therefore does not use them is safe. The same applies to, e.g., Rust: any Rust program may use unsafe blocks. That Rust programs may contain unsafe blocks does not make Rust implicitly unsafe. Even using unsafe blocks does not, by itself, make the program unsafe.
- throw10920 4y ago
  Your dodging of my question leads me to believe that the answer is "no". Therefore, "modern C++" is still unsafe. > Even using unsafe blocks does not, by itself, make the program unsafe. This is false. "Unsafe" means that there is the potential to cause memory safety bugs. Unsafe blocks and C++ cause this, by definition. "Unsafe" does not mean that a memory safety bug actually exists. Moreover, I didn't mention anything about Rust in my comment.

guhidalg 4y ago

Pedantic clarity isn't helping your argument. The fact that you can choose to write C while calling a C++ compiler means people will always call it C/C++.

pencilguin 4y ago
It means that conclusions based on pretending it is a meaningful expression are tainted at the source, and thus may be presumed invalid without further examination. If you are coding C or pre-modern C++, then you are not coding modern C++, regardless of the compiler you happen to build with.
- sitkack 4y ago
  Your parent comment is an example Not True Scotsman [1] and circular logic. Your claim that modern C++ doesn't ship memory safety issues is a fallacy not worth my time for a rebuttal. https://en.wikipedia.org/wiki/No_true_Scotsman https://en.wikipedia.org/wiki/No_true_Scotsman
  - pencilguin 4y ago
    C++20 is an International Standard, superseding all previous Standards. Programs that use C++20 constructs in preference to pre-C++11 constructs are objectively more modern, to the exact degree they do.
    - samatman 4y ago
      Your position could be taken seriously if, and only if, there were a version of the language which doesn't contain all the cruft. As in, there are compilers which won't compile it. Instead, mid-90s C++, with all the leaks, is valid C++, 20 or otherwise. No true C++20 program is memory unsafe... unless you use a normal pointer, which is always available and will bork you just as hard as in C.
      - pencilguin 4y ago
        Where there is no need for a native pointer to be used, as almost everywhere, and no pointer is used, that code is objectively more modern than code that uses the pointer anyway. It is very rare to need to use a native pointer in modern C++ code. The need for one is strictly less common than a need for an unsafe block in Rust. Your argument applies equally well to Rust: any Rust program may include unsafe blocks. That any program may contain unsafe blocks does not make Rust implicitly unsafe. That a Rust program does (transitively) contain unsafe blocks does not make it an unsafe program. All substantial Rust programs at least transitively contain unsafe blocks. Thus, your argument is invalid.