3 ms·

There is absolutely a benefit, but it doesn't sound like one to you: it explicitly requires you to know that you're actually doing something with memory, which

There is absolutely a benefit, but it doesn't sound like one to you: it explicitly requires you to know that you're actually doing something with memory, which rapidly deteriorates as a concept for developers once they no longer have to be cognizant of the fact that they are indeed actually using it. I prefer a world where people actually think about the resources they're using.

jcranmer 3y ago
But does that benefit actually exist? The approach of languages like C++ or Rust isn't to hide memory in the way a GC'd environment like Java or Python does (although C++ does have historical baggage with its copy constructors)--this feels to me like it's the same problem I mentioned in my first comment, that you're focused on contrasting C with managed languages and ignoring the space of non-managed languages. And, anecdotally, from what I've seen perusing various Rust crates, my sense is that too many Rust programmers actually spend too much time worrying about their memory usage, designing extensive and cumbersome zero-copy interfaces when, no really, you should just copy that 5-byte string to your own storage. I don't see how having to remember to always add in calls to free, with the cost of using more memory if you forget to do so, is really supposed to help you minimize your memory usage. That's the main difference we're talking about here...
- torstenvl 3y ago
  Remembering to use free() is a lot easier than remembering the inner workings of each and every destructor of each and every object you use. Will destroying this window free the memory for this font instance? Will destroying this DOCX processing object close the file? Who knows? But when the rule is just to clean up after yourself, it's a lot easier to remember.