by jurschreuder
9 subcomments
- I don't know why people use 'new' and 'delete' in all the examples how memory in C++ works because you never normally use them during coding only if you want to make your own container which you might do once to learn about the internals.
C++ by default creates objects by value (opposed to any other language) and when the variable goes out of scope the variable is cleaned up.
'new' you use when you want to make a global raw pointer outside of the normal memory system is how I would see it. You really never use it normally at least I don't.
A good rule of thumb is not to use 'new'.
- C++: Where you can accidentally deallocate an object that's still in the call stack. (true story)
- Why are some examples full of errors? The `set_vec` method for instance does not bind the reference, you can't change the reference itself... so the code would simply copy the vector and there would be no dangling reference... And `B` is missing a constructor since the default constructor would be ill-formed (you can't default initialize a reference).
Anyway the article is quite approachable, do not take my criticism to shy away from writing!
- Does anyone reading this have links to people who have written specifically about a C++ ownership model that rejects the smart_ptr/RAII/friends model in favor of an ownership model that embraces bulk allocations, arenas, freelists, etc? I know there are groups of highly productive programmers that feel the traditional C++ ownership model is hot garbage, and I'd love a resource that puts down specific arguments against it, but I've never come across one myself.
Edit: clarity
- I think in the `Move` section the delete[] should be delete[] old_buffer; rather than new_buffer;
- Why there is the calling of "read(buffer.get());" in the first example (inside of the 'while' loop)?
It is a 'char *buffer' type, unless I'm mistaken raw pointers don't have methods/member functions?
- this article showes very nice what i do not like in modern c++. Packing easy concepts like lifetime and ownership of data behind complex generic named classes. don't get me wrong; i still like OOP, i even use OOP in c (wel OOP like code) but i do not like the concept of packing easy things in complex ones. perhaps im a litte old :)
- The title reminds of this:
https://youtu.be/TGfQu0bQTKc?si=7TiDRic6LaWI1Xpc&t=70
"In Rust you need to worry about borrowing. In C++ you don't have to worry about borrowing; in C++ you have to worry about ownership, which is an old concept..." :-P
- C++ doesn’t really have an ownership system. You can use certain language features to implement certain kinds of ownership discipline, but the language itself doesn’t really have an opinion on who should own what. For example, the article talks about cases where a returned value “must” be deallocated by the calling code, but there is no “must” about it as far as the language is concerned. You’re perfectly at liberty to allocate something without ever freeing it (and this isn’t even a memory leak if the value is needed throughout the lifetime of the program).
by fleshmonad
0 subcomment
- Author currently unemployed type post to state in zoomerspeech
Hacker News