Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A simple garbage collector for C

github.com

Post reply on HN
Print view View original

41–50 of 62 posts

Re: Show HN: A simple garbage collector for C

#41

Post by augustk »

simias wrote: post #19
seventh-chord wrote: post #15

Earlier quoted context omitted.

Regarding having tons of exit points, I find it actually adds no more cognitive load to use only a single return per function, compared to having multiple returns and keeping resource-freeing up-to-date for each. Most of the challenge in writing code with a single return seems to come from the fact that I'm not used to doing it. Of course, sometimes it leads to heavily nested control flow, although I'm not sure yet w…

What you say makes sense but I'd advise beginners reading this comment not to overdo it. I've seen new coders "cargo culting" this one-return-per-function rule and leading to code that was, in my opinion, unnecessarily complicated. For instance parameter validation is one instance where I think an early return is very much warranted. There you typically have no cleanup to do since it's effectively the prelude of the…

> For instance parameter validation is one instance where I think an early return is very much warranted. There you typically have no cleanup to do since it's effectively the prelude of the function.

That's what the assert statement is for; checking pre- and postconditions.

Re: Show HN: A simple garbage collector for C

#42

Post by pdpi »

tjpnz wrote: post #35
davnicwil wrote: post #26

Just out of interest for people not familiar with C, latest goings on there etc, what's the usecase where you'd want a garbage collector in C? My (very surface level) understanding was always the trade off for the increased manual effort of using C - manual memory management being one example - was that you could tailor your solution exactly to your usecase for increased performance / lower resource use. If you're go…

I could imagine something like this being applicable towards large legacy codebases with a history of memory leaks and segfaults. With legacy codebases you're often only able to tread water and won't be in a position to track everything to it's root cause.

Adding a GC to such a code base is a terribly complex endeavour and would only make things even worse though.

Re: Show HN: A simple garbage collector for C

#43

Post by pdpi »

davnicwil wrote: post #26

Just out of interest for people not familiar with C, latest goings on there etc, what's the usecase where you'd want a garbage collector in C? My (very surface level) understanding was always the trade off for the increased manual effort of using C - manual memory management being one example - was that you could tailor your solution exactly to your usecase for increased performance / lower resource use. If you're go…

Think about it the other way around — Java, Python, JavaScript all have garbage collectors. What language are those GCs written in? How does the runtime keep track of the objects in those languages, and how is the lifecycle for that tracking managed?

"Writing a GC in C" (or equivalent language) is not so much a strange thing as it is an inevitability.

Re: Show HN: A simple garbage collector for C

#44

Post by jeen02 »

pdpi wrote: post #43
davnicwil wrote: post #26

Just out of interest for people not familiar with C, latest goings on there etc, what's the usecase where you'd want a garbage collector in C? My (very surface level) understanding was always the trade off for the increased manual effort of using C - manual memory management being one example - was that you could tailor your solution exactly to your usecase for increased performance / lower resource use. If you're go…

Think about it the other way around — Java, Python, JavaScript all have garbage collectors. What language are those GCs written in? How does the runtime keep track of the objects in those languages, and how is the lifecycle for that tracking managed? "Writing a GC in C" (or equivalent language) is not so much a strange thing as it is an inevitability.

Writing a GC for C is pretty strange.

Re: Show HN: A simple garbage collector for C

#45

Post by de_watcher »

davnicwil wrote: post #26

Just out of interest for people not familiar with C, latest goings on there etc, what's the usecase where you'd want a garbage collector in C? My (very surface level) understanding was always the trade off for the increased manual effort of using C - manual memory management being one example - was that you could tailor your solution exactly to your usecase for increased performance / lower resource use. If you're go…

You've answered your own question. For some part of the system you do one type of memory management, for other part you use the GC. If you use a higher level language for everything then writing the performant part will be tricky.

Re: Show HN: A simple garbage collector for C

#47

Post by Koshkin »

jeen02 wrote: post #44
pdpi wrote: post #43

Earlier quoted context omitted.

Think about it the other way around — Java, Python, JavaScript all have garbage collectors. What language are those GCs written in? How does the runtime keep track of the objects in those languages, and how is the lifecycle for that tracking managed? "Writing a GC in C" (or equivalent language) is not so much a strange thing as it is an inevitability.

Writing a GC for C is pretty strange.

In the world of C nothing is strange. (Which is part of why it is future-proof.)

Re: Show HN: A simple garbage collector for C

#48

Post by dgellow »

saagarjha wrote: post #23
dgellow wrote: post #18

Earlier quoted context omitted.

I know that's not directly what you're asking for, but I found the other day that "C++ Core Guidelines" have a helper library "GSL_util" that provide something similar to Go's defer. The implementation is very simple, it's just using a class for its destructor: template class final_act { public: explicit final_act(F f) noexcept : f_(std::move(f)), invoke_(true) {} final_act(final_act&& other) noexcept : f_(std::move(…

Of course, in C++ the need for such constructs is reduced due to RAII and scoping running destructors automatically. This is useful when you need to interact with C libraries that you don’t want to wrap in C++ (and when I was doing something like this in the past, I rolled my own as well).

> This is useful when you need to interact with C libraries that you don’t want to wrap in C++

Yep! I really like the defer pattern for those situations :)

Re: Show HN: A simple garbage collector for C

#49

Post by pdpi »

jeen02 wrote: post #44
pdpi wrote: post #43

Earlier quoted context omitted.

Think about it the other way around — Java, Python, JavaScript all have garbage collectors. What language are those GCs written in? How does the runtime keep track of the objects in those languages, and how is the lifecycle for that tracking managed? "Writing a GC in C" (or equivalent language) is not so much a strange thing as it is an inevitability.

Writing a GC for C is pretty strange.

It’s really not. If you’re implementing a language runtime for language X, and the runtime is written in C, then writing the X GC actually means “writing a GC in C, for the subset of C allocations that represent X allocations.”

E.g. Python objects are represented as PyObject values in CPython. Saying that Python is garbage collected is equivalent to saying PyObjects are garbage collected. Sure enough, PyObject contains the ref count necessary for its GC.

Post reply on HN