6 ms·
>I can't help but notice that C++ community has a strong bias against garbage collection. [...] >Why can't you acknowledge that there are problems that have GC
by jasode 10y ago
>I can't help but notice that C++ community has a strong bias against garbage collection. [...]
>Why can't you acknowledge that there are problems that have GC as the only and best solution?
Your prelude and the followup question is not well-formed.
C++ programmers do not have a bias against GC as a specific problem-solving technique. In fact, expert C++ programmers can embrace GC so much that they can write an entire virtual machine[1] with GC and a DSL[2] for that vm that takes advantage of memory safety. Both the CLR vm and the (original) C# compiler were written by C++ programmers.
What the C++ community doesn't want is GC in the C++ base language itself or the standard runtime. That's a very different concept from a generalized "C++ bias against GC".
In other words, the following is unacceptable:
std::string x = "Hello, " + fullname; // cpu cycles spent on GC
Those cpu cycles spent on constantly checking if "x" is no longer reachable is cpu power that's taken away from rendering frames of a 60fps game, or computing numeric equations or high speed quantitative trading. C++ programmers don't want GC as a global runtime that you can't opt out of. Also, global GC often requires 2x-3x the memory footprint of working memory which is extremely wasteful for the resource constrained domains that C++ is often used in.
Herb Sutter's presentation is compatible with "pseudo-GC-when-you-need-it" without adding GC to the entire C++ standard runtime.
[1]https://en.wikipedia.org/wiki/Common_Language_Runtime https://en.wikipedia.org/wiki/Common_Language_Runtime
[2]https://en.wikipedia.org/wiki/C_Sharp_(programming_language) https://en.wikipedia.org/wiki/C_Sharp_(programming_language)
- ingenter 10y ago> Your prelude and the followup question is not well-formed. Thank you for your feedback, I appreciate it. > C++ programmers do not have a bias against GC as a specific problem-solving technique. Expert C++ programmers can embrace GC Please watch this portion of the video, and the way the speaker is pronouncing the word "collect": https://www.youtube.com/watch?v=JfmTagWcqoE#t=1h5m25s https://www.youtube.com/watch?v=JfmTagWcqoE#t=1h5m25s Regarding general-purpose GC: I don't support using GC for everything. If there is a problem that can only be solved with GC, it doesn't mean that we should express our entire running programs in terms of dynamic cyclic graphs. I believe we can do much better, with much fewer resources.
- jasode 10y ago>Please watch this portion of the video, and the way the speaker is pronouncing the word "collect": Herb was deliberately using circumlocution to avoid the phrase "garbage collection" so as to not poison the well. The latter part of the video explains his reasoning for presenting it that way: https://www.youtube.com/watch?v=JfmTagWcqoE&t=1h32m55s https://www.youtube.com/watch?v=JfmTagWcqoE&t=1h32m55s >I don't support using GC for everything. [...] I believe we can do much better, with much fewer resources. This is a statement that sounds reasonable and balanced . How can anyone possibly disagree with it?!? The issue is that it's very difficult to take that universal wisdom and construct a real programming language that satisfies all the following properties seamlessly and elegantly: 1) language that has optional GC 2) has zero cost when not using it. This means no active tracing loop that checks object graphs and no large memory blocks reserved to allow reallocation and defragmention. 3) transparent syntax that's equally elegant for manual memory or GC in the same language To make your GC-when-appropriate advice real, one has to show a real implementation. E.g. one can fork the GCC or LLVM compilers and add GC to it. Or fork the Java OpenJDK compiler and show how syntax can remove the GC on demand. Or construct a new language from scratch. There may be some lessons learned from the D Language backing away from GC. Also, Apple Objective-C retreated from GC as well.
- ingenter 10y ago> To make your GC-when-appropriate advice real, one has to show a real implmentation. I haven't tested it closely, but I believe that Rust with this crate: https://github.com/Manishearth/rust-gc https://github.com/Manishearth/rust-gc is an implementation for "GC only when you need it".
- DougBTX 10y agoMicrosoft's Managed C++ is frankly scary, but its gc root type seems pretty close to this.
- DannyBee 10y agoRight, but they pay a different cost there that isn't listed: "It's not entirely compatible with the existing language" private and multiple inheritance do not work, for example (yes, i know some of this is fixable, but some is not) public __gc class one { int i; }; public __gc class two: private one { int h; i = h; }; //error __gc class a {}; __gc class b {}; __gc class c: public a, public b {}; //will produce an error etc
- adrianratnapala 10y agoThere is an advantage to universal GC: it can simplify interfaces. For example, in C every time a `const char *` appears in an API there has to be an implicit contract about who owns the string and how to free it. A language like Rust improves on this by enforcing such contracts, but the contracts still complicate every interface. In a GC'd language you can just forget about these issues and just treat strings (and other immutable objects) almost as if they were ordinary fixed-sized values.
- steveklabnik 10y agoNobody says GC has no advantages, the claim is that its disadvantages don't always offset them.
- jdright 10y agoAnd C++ is all about choice trade-offs. Put very simply: do your choice for your problem and deal with its consequences.
- hackits 10y agoThe way C/C++ get around the implicit ownership of const char * is everyone copies data around.
- chrisseaton 10y agoI agree with you, but in this > std::string x = "Hello, " + fullname; // cpu cycles spent on GC you are already spending cycles on memory management (if C++ allocates character data on the heap which I think it does). You are searching for free space in the heap, possibly synchronising to do that, and so on. With a GC you may even use less cycles here! For example a copying GC could mean that you can allocate with a simple thread local bump pointer. So in your statement you are already paying an unknown cycle cost for memory management. Why do you care if it's GC? Your answer is probably the variance in the number of cycles - the noticeable pauses - which is a reasonable concern.
- to3m 10y agomalloc/free/etc. will only cost when they're called; GC can be a continuous expense even when there's no collection.
- pjmlp 10y agoIt is a matter how it is implemented.
- pkolaczk 10y agoMost GCs will not cost you a single cycle if you never allocate.
- daemin 10y agoBut in most GC languages there is nothing you can do without allocating. Creating an object is already allocating it on the heap, printing a string will also allocate.
- deleted 10y ago[deleted]
- pjmlp 10y agoNot in GC languages that also have value types. For example you can do all of that in Modula-3, Active Oberon, Component Pascal and many others without allocating more than in C for example. Mixing all GC enabled languages in the same box is a mistake.
- pjmlp 10y agoA GC API definition is already in the standard. It was added in C++11.
- T-zex 10y agoAnother aspect against GC is system determinism. Unmanaged runtime is more deterministic and is often faivored in real time applications.
- pjmlp 10y agoOnly if malloc()/free() don't need to call OS APIs, if it happens good luck with being deterministic.
- nanolith 10y agoOne does not need to ever use malloc()/free() or new/delete in C++. For instance, it is very common to use just the DATA and BSS segments in embedded code, and rely on placement-new, which is always deterministic. Dynamic memory allocation is also a choice in C++.
- pjmlp 10y agoGoing a bit off topic, that is something you can also do in Ada or SPARK, while having a more type safe language. My problem when I used to code in C++ was working with others in corporate projects. It didn't matter how I strived to write modern code, making use of best practices to write safe code, there were always team members that never moved beyond C with Classes and nevermind having some processes in place to avoid precisely that. Even nowadays, I get the feeling most developers don't make any use of static analysis.
- nanolith 10y agoSadly, I don't think that's a problem that a language alone can solve. Ada, for instance, is awesome with its runtime enforcement of design contracts, but all a programmer needs to do is change the contract and chaos ensues. I'm a huge fan of strong typing. I'm also actively trying to find ways to improve static analysis and formal methods. But, if you can't trust your developers, it all eventually breaks down. I find that for most mature projects, a good developer needs 3-6 months of ramp-up time, which should include knowledge transfer, training, and restricted commit access. The point of this isn't to haze the developer, but instead to give him/her a chance to fully grok the intent of the mechanisms in the code base and to (hopefully) present and socialize better options in a controlled way. More and more, I've come to the conclusion that a strong team mechanic is one of the mandatory components of good software. DBC, code reviews, unit testing, formal analysis, and static analysis all help to reinforce this mechanism, but if the tribal knowledge of the team breaks down, then so ultimately will the quality of the software produced.
- pkolaczk 10y ago"Also, global GC often requires 2x-3x the memory footprint of working memory which is extremely wasteful for the resource constrained domains that C++ is often used in." Memory fragmentation in manual memory management often comes at a similar or higher cost, which is often "forgotten" and neglected, because it is hidden: https://bugzilla.mozilla.org/show_bug.cgi?id=666058#c31 https://bugzilla.mozilla.org/show_bug.cgi?id=666058#c31 And fragmentation may grow over time much more than the typical GC overhead. Then you have to do a "forced GC" that is restarting the application. Often happens to my phone or browser. I'm not sure if it is more due to fragmentation or more due too plain old memory leaks.