Idiomatic C code has no allocations or copies. You're thinking of C++.
Conversation
I'm specifically talking about modern C++ styles using lots of moves, references, iterators / ranges and more recently types like en.cppreference.com/w/cpp/string/b. A lot of effort goes into avoiding copies, including in very dangerous / fragile ways since it's not memory safe like Rust.
2
1
I think it bites off more than it can chew. It's great to do things like zero copy parsing with string views when you actually have memory safe, but it's horrifying in C++. It would be horrifying in C too but I don't see people doing this kind of stuff pervasively.
1
1
C++ lets people use super dangerous abstractions in a way that looks very clean and safe. A lot of modern C++ is extremely dangerous despite seeming very high level and concise. It just isn't suited for the code styles that people are using (lots of closures, iterators, etc.).
1
1
3
Some parts though are actual huge improvement over C. uniq_ptr for example, it's actually is zero (runtime) cost adds to clarity, adds to safety, and it's hard to be as optimized (e.g., allocate for ptr and data once for shared_ptr).
1
Except that unique_ptr is still completely unsafe due to use-after-free via references, use-after-move and null pointer dereferences. Avoiding memory leaks is a separate thing from memory safety. Implicit destruction in a language without memory safety encourages use-after-free.
1
It's a lot different in Rust where the language enforces memory safety and prevents dangling references (including iterators, string views, etc. and anything else made out of lightweight references), use-after-free, data races and so on. Fancy C++ encourages having these issues.
1
I'm not saying that they're bad language features. It's awesome having pervasive use of lightweight references, iterators, string views, etc. but when you use something like iterators or en.cppreference.com/w/cpp/string/b in C++, it's an extreme danger. One tiny mistake is an RCE vuln.
1
Iterators are evil, I perfectly agree. I don't see how can uniq_ptr cause those memory errors more than a raw pointer.
None of what you said can happen if you don't let the raw pointer escape, or am I missing something?
1
Yes, you're missing something. It clearly does absolutely nothing to prevent NULL dereferences or use-after-move so lets skip those. To use unique_ptr, you need to copy from it or get a reference. That reference isn't safe, and std::unique_ptr will still free with it active.
1
Why would you be using std::unique_ptr in the first place if you just want a value to copy around? That wouldn't make any sense. It's used to manage the lifetime of a dynamic allocation, where you are using it via references, not copying the contents out for every single use.
Similarly, for std::shared_ptr, you are still going to be using references to it, including mutable references, which are extremely dangerous in C++ since they can invalidate other references to the contents by changing the length of a container, a dynamic type, variant type, etc
1
The std::shared_ptr design also encourages data races, since it goes out of the way to provide thread safety with extremely inefficient atomic reference counting, but doesn't provide a locking mechanism paired with it.
1
Show replies