3 ms·

C++ is safer than C? How?

JTyQZSnP3cQGa8B 2y ago
You can write whole applications that compiles to the same assembly code without using any kind of memory management thanks to the destructors, smart pointers, and all the objects of the STL.
- flohofwoe 2y ago
  This just pushes the problem into the C++ stdlib, which has plenty of memory-corruption issues too but just calls it 'undefined behaviour' (see things like dangling std::string_view, missing range checks in containers or iterator invalidation). In C you avoid those issues by reducing dynamic memory allocations to a minimum, prefering value types over reference types and using function APIs as 'safety boundaries' (instead of directly poking around in random data). Different approach, but not any less safe than C++.
  - vlovich123 2y ago
    > In C you avoid those issues by reducing dynamic memory allocations to a minimum, prefering value types over reference types and using function APIs as 'safety boundaries' "In Rust that's just pushing the problem to the borrow checker and codegen which has plenty of memory corruption issues too but just calls it "bugs". In C++ you avoid those issues by reducing dynamic memory allocations to a minimum, and using checked APIs as 'safety boundaries' instead of directly poking around random arrays. Different approach but not any less safe than C++". Both statements are pretty ridiculous. It's pretty clear that moving up in terms of the safe abstractions that are possible makes your code safer because the safety is there when you reach for that kind of programming paradigm & the programming paradigms you need are typically a property of the problem domain rather than the language (it's it's the intersection of "how is this problem solved" and "what tools does the language give you"). In C it gives you few tools and you either twist into a pretzel trying to stick to that or you write our own tools from scratch every time and make the same but different mistakes over and over. No language is perfect and all will guide you to different takes on the same problem that better suit to its paradigm, but there are intractable parts that will force you to do things (e.g. heap allocation and more involved ownership semantics are not uncommon). Moreover C very limited ability to manage your own codebase to define API boundaries - the only tool is opaque types with a defined set of functions declared in 2 different files.
    - uecker 2y ago
      The opaque types in C are great though. And because no info leaks via header, you have very fast compilation. The y"ou write from scratch every time" is a weird statement. I do not delete my own code after each project and there exist plenty of libraries.
UebVar 2y ago
Somewhat separating owning and non owning memory in the type system goes a long way. Also a much better standard library and a stricter typing discipline. The fact that it's mostly backwards compatible means you can reproduce almost all issues of c in c++ awell, but the average case fares much better. Real world C++ does not have double-frees, for example. (As real world C++ does not have free() calls).

You can write whole applications that compiles to the same assembly code without using any kind of memory management thanks to the destructors, smart pointers, and all the objects of the STL.

flohofwoe 2y ago
This just pushes the problem into the C++ stdlib, which has plenty of memory-corruption issues too but just calls it 'undefined behaviour' (see things like dangling std::string_view, missing range checks in containers or iterator invalidation). In C you avoid those issues by reducing dynamic memory allocations to a minimum, prefering value types over reference types and using function APIs as 'safety boundaries' (instead of directly poking around in random data). Different approach, but not any less safe than C++.
- vlovich123 2y ago
  > In C you avoid those issues by reducing dynamic memory allocations to a minimum, prefering value types over reference types and using function APIs as 'safety boundaries' "In Rust that's just pushing the problem to the borrow checker and codegen which has plenty of memory corruption issues too but just calls it "bugs". In C++ you avoid those issues by reducing dynamic memory allocations to a minimum, and using checked APIs as 'safety boundaries' instead of directly poking around random arrays. Different approach but not any less safe than C++". Both statements are pretty ridiculous. It's pretty clear that moving up in terms of the safe abstractions that are possible makes your code safer because the safety is there when you reach for that kind of programming paradigm & the programming paradigms you need are typically a property of the problem domain rather than the language (it's it's the intersection of "how is this problem solved" and "what tools does the language give you"). In C it gives you few tools and you either twist into a pretzel trying to stick to that or you write our own tools from scratch every time and make the same but different mistakes over and over. No language is perfect and all will guide you to different takes on the same problem that better suit to its paradigm, but there are intractable parts that will force you to do things (e.g. heap allocation and more involved ownership semantics are not uncommon). Moreover C very limited ability to manage your own codebase to define API boundaries - the only tool is opaque types with a defined set of functions declared in 2 different files.
  - uecker 2y ago
    The opaque types in C are great though. And because no info leaks via header, you have very fast compilation. The y"ou write from scratch every time" is a weird statement. I do not delete my own code after each project and there exist plenty of libraries.

UebVar 2y ago

Somewhat separating owning and non owning memory in the type system goes a long way. Also a much better standard library and a stricter typing discipline. The fact that it's mostly backwards compatible means you can reproduce almost all issues of c in c++ awell, but the average case fares much better. Real world C++ does not have double-frees, for example. (As real world C++ does not have free() calls).