aka “bros: in order to be rich, just don’t be poor.”
Just restart the app every day /s
ITT: a lot of people who neither read the article, nor understand what the term “memory leak” means.
To be clear, he’s not saying “just code better”, as the title implies. It’s a really poor choice of title.
you are going to mess up somewhere and get leaks, stray pointers, etc. This is true independently of how conscientious you are with your allocations:
He goes on to say, effectively, “Don’t use new/delete/malloc/free if you can help it. Use smarter mechanisms.”
C++'s so called smarter mechanisms are ugly af. I would rather my RAM crash and burn than use its standard library.
yeah. I’d rather use C and statically allocate everything up front, even if that’s not a great fit
When I did embedded programming that’s what I did. Nothing was dynamically allocated. It also allowed me to write a debugger that would watch how variables changed by just directly reading from memory, chart them, and and stuff like that.
Ya, I don’t think he actually said that since it’s not mentioned in the referenced article. What’s actually meant is “by writing code that doesn’t have any memory management”.
The memory leaks section just feels like an introduction to smart pointers as though they’re some complex concept. Also, the page is showing its age by mentioning the now-removed
auto_ptrinstead of something likeunique_ptr.Anyway, scrolling down a little more:
Why can’t I assign a vector<Apple*> to a vector<Fruit*>?
This actually comes up in C# with arrays. Copying their example here:
object[] array = new String[10]; // The following statement produces a run-time exception. // array[0] = 10;It may have been a design mistake not to make C#'s arrays invariant, though I don’t know the state of that debate today.
Invariant?
Neither covariant nor contravariant.
supertype[] is not a supertype of subtype[] if supertype and subtype alone are in that relationship, because the mutability of arrays means that the Liskov substitution principle doesn’t hold.
(These are all something you’ll probably find good explanations of on Wikipedia.)
No, this is kinda right. Memory leaks =/= memory safety. Memory leaks are just when you keep allocating more and more memory, and can be done in any language. If I make accidentally make a list that infinitely grows in python, that’s a memory leak.
There are techniques to write code that is mostly free of leaks, which is what he is referring to.
Memory safety, on the other hand, doesn’t seem to be mentioned on that page…
A “true” memory leak isn’t just memory that is never freed, it’s memory that CAN’T be freed. Usually because the handle / pointer to it was thrown away.
The distinction isn’t really all the important though, it all looks the same as far as how the program functions.
all these newfangled languages with their “memory safety” and “helpful tooling”, pah. all a real programmer needs is a hole punch and a roll of paper.
Simpler times.
A reminder that Bjarne doesn’t actually code. He is a bureaucrat.
Perfect username.
Not as perfect as the people objecting to a factual statement.
They must be answering Bjarne’s call to defend the honor of C++ against evil enemies 😛
Anybody claiming C++ is safe or can be made safe is clinically insane 😅
lol “jUst wRiTe bETteR cOde”
