11 ms·
> 2. I basically don’t believe that memory management is not hard. If you try to write Java in C++ then probably the result is verbose. With some practice thou
by jstimpfle 5y ago
> 2. I basically don’t believe that memory management is not hard.
If you try to write Java in C++ then probably the result is verbose. With some practice though, memory management needn't be hard - if memory management is hard that hints lack of organization.
Smaller, script-like programs where there is no place for large-scale organization, are a different story (especially in C and C-like C++) and GC'ed languaged might be more convenient.
- dan-robertson 5y agoI think the evidence outweighs opinions, and I think the evidence says that it is hard to avoid memory management problems in C++.
- FpUser 5y agoI do not have single explicit memory management call in my product of very decent size written in modern C++. So no , I have no idea where did you fish your "evidence" from.
- dan-robertson 5y agoI don’t understand what you’re trying to say? Do you mean that you don’t call malloc? Because that is totally not the point. For example, you could create a new object, pass a reference to it to some function that stores it in a hash table, reach the end of your function where the object is automatically deleted, and then have something try to read the object out of the hashtable. Nowhere do you need to call malloc or do any explicit memory management and yet you have a use-after-free bug. Some evidence can be found in my reply to the sibling comment which talks about chrome, a large and very well-tested C++ application mostly in a modern style. There are also surveys of security vulnerabilities that find a large percentage are due to incorrect memory management. Maybe I’m just missing the point though as I think I’m only writing obvious well-known things and you probably mean something more nuanced?
- FpUser 5y ago>"For example, you could create a new object, pass a reference to it to some function that stores it in a hash table, reach the end of your function where the object is automatically deleted, and then have something try to read the object out of the hashtable." Emplace constructs copy of object in the container. You should be fine.
- dan-robertson 5y agoWhat are you trying to argue here? I’m not claiming that the thing I described is good, only that it is a way to get memory management wrong without calling malloc, so the fact that emplace exists is irrelevant. I think I still don’t understand what your point is because you seem to be arguing against something I’m not claiming.
- FpUser 5y agoIf you are actively looking to shoot yourself in a foot be my guest. But it is your problem, not the one of the language.
- jstimpfle 5y agoIn your example, storing a pointer to an item in the hashtable in a context that potentially outlives the hashtable items could qualify as "bad memory management". Long-lived cross-context pointers in general I frown upon (most pointers I use have their lifetime bound to a function call), although there are no hard rules of course, and you have a point in that these errors are not detected by most type systems or probably even static analyzers. Well, it's still a smell, because we know these types of problems and we know many ways to avoid most of them. I'm saying this all to support the claim that memory management needn't be hard, not to claim that there aren't any exploitable memory bugs out there, which would be an insane claim.
- pjmlp 5y agoGrep AOSP source code then.
- FpUser 5y agoWTF is AOSP and why would I grep it?
- ncmncm 5y agoAOSP is an ancient collection of Android apps Google published.
- pjmlp 5y agoThe public source code for Android, written by a company that seats on ISO C++.
- zarkov99 5y agoI think it depends a lot on experience and wether the code base is post C++ 11. Modern codebases like clang or chrome do not seem to have any more memory management issues than something like Intellij. Personally I wrote system software in C++ for 10 years and memory management was a problem maybe once or twice.
- dan-robertson 5y ago> chrome See https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/opec-1/Google-Chrome.html https://www.cvedetails.com/vulnerability-list/vendor_id-1224... for a list of RCE vulnerabilities. I see a bunch of memory management problems there. Also note that chrome is likely much better tested than some other C++ project, and lots of tools are used to search for potential vulnerabilities or invalid memory use as well as fuzzing and crash reports from a large install base. I don’t know how this compares with IntelliJ/Java (which I also don’t particularly like). I would expect other C++ applications to have a higher defect rate than chrome due to less testing/tooling but also likely a lower attack surface area.
- jstimpfle 5y agoNever contain programs so few bugs, as when no debugging tools are available - Niklaus Wirth Fuzzers and testing can detect bugs but I don't see how they can make a contribution to a reasonable software structure (I believe that bad structure is the prime cause of bugs).
- dan-robertson 5y agoThe other tools being talked about are static analysis tools or runtime instrumentation both designed specifically to try to find bad memory use patterns. I don’t mean this in a rude way, but I don’t care what you believe, because the thing I care about is evidence. If you have some actual evidence for your claim, I would be interested. (I also believe there can be improvements from better code structure in a rewrite and this can make up for a significant portion of the improvements from a ‘let’s rewrite it all in rust’ project).
- pjmlp 5y agoAlso known as MFC, PowerPlant, Turbo Vision, CSet++, Taligent, OWL, ATL, Symbian, Motif++,... all on average 5 years old when Java came into the world.
- jstimpfle 5y agoWell, they knew how to write Java in C++ even before Java came out...
- pjmlp 5y agoOr Java was actually created by C++ developers that kept their habits. Just like JEE was originally written in Objective-C during the OpenSTEP days as the Distributed Objects Everywhere framework, and then ported to Java afterwards.