←back to thread

Giving C a superpower: custom header file (safe_c.h)

(hwisnu.bearblog.dev)
271 points mithcs | 1 comments | 17 Nov 25 10:40 UTC | HN request time: 0s | source
Show context
cachius ◴[17 Nov 25 12:56 UTC] No.45953162[source]▶
A recent superpower was added by Fil aka the pizlonator who made C more Fil-C with FUGC, a garbage collector with minimal adjustments to existing code, turning it into a memory safe implementation of the C and C++ programming languages you already know and love.

https://news.ycombinator.com/item?id=45133938

https://fil-c.org/

replies(3): >>45953284 #>>45953390 #>>45954377 #
762236 ◴[17 Nov 25 13:30 UTC] No.45953390[source]▶
Why would I want to run a garbage collector and deal with it's performance penalties?
replies(4): >>45953453 #>>45953598 #>>45953991 #>>45961132 #
sesm ◴[17 Nov 25 14:42 UTC] No.45953991[source]▶
IDK about Fil-C, but in Java garbage collector actually speeds up memory management compared to C++ if you measure the throughput. The cost of this is increased worst-case latency.

A CLI tool (which most POSIX tools are) would pick throughput over latency any time.

replies(5): >>45954231 #>>45954275 #>>45954762 #>>45954883 #>>45958686 #
1. milch ◴[17 Nov 25 21:42 UTC] No.45958686{3}[source]▶
Depending on the CLI tool you could even forego memory management completely and just rely on the OS to clean up. If your program completely reads arbitrary files into memory it's probably not the best idea, but otherwise it can be a valid option. This is likely at least partly what happens when you run a benchmark like this - the C++ one cleans everything up nicely if you use smart pointers or manual memory management, while the Java tool doesn't even get to run GC at all, or if it does it only cleans up a percentage of the objects instead of all of them.