101–110 of 277 posts
The post mentions cgrep several times, but I don't see a link to the code. Is it available somewhere? Github has several repositories named cgrep, but the first results are written in other languages than C (Haskell, Python, Typescript, Java, etc).
C++: "look at what others must do to mimic a fraction of my power" This is cute, but also I'm baffled as to why you would want to use macros to emulate c++. Nothing is stopping you from writing c-like c++ if that's what you like style wise.
> I'm baffled as to why you would want to use macros to emulate c++. I like the power of destructors (auto cleanup) and templates (generic containers). But I also want a language that I can parse. Like, at all. C is pretty easy to parse. Quite a few annoying corner cases, some context sensitive stuff, but still pretty workable. C++ on the other hand? It’s mostly pick a frontend or the highway.
Earlier quoted context omitted.
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.
You also pay for the increased throughput with significant memory overhead, in addition to worst-case latency.
In the best cases, you’re losing a huge amount of performance vs. an equivalent non-GC system. In the worst, it affects interactive UI performance with multi-second stalls (a suitably modern GC shouldn’t do this, though).
The real problems start when you need to manage memory lifetimes across the whole program, not locally. Can you return `UniquePtr` from a function? Can you store a copy of `SharedPtr` somewhere without accidentally forgetting to increment the refcount? Who is responsible for managing the lifetimes of elements in intrusive linked lists? How do you know whether a method consumes a pointer argument or stores a copy to it somewhere?
I appreciate trying to write safer software, but we've always told people `#define xfree(p) do { free(p); p = NULL; } while (0)` is a bad pattern, and this post really feels like more of the same thing.
Nice, but if the intention is portability my experience has unfortunately been that you pretty much have to stick to C99. MSVC’s C compiler is rough, but pretty much necessary for actual cross platform. I have my own such header which has many, many things like the OP’s. As much as I would find it constantly useful, I don’t have a cleanup utility because of this. But if you can stay out of MSVC world, awesome! You ca…
MSVC now supports C17.
Earlier quoted context omitted.
For new projects, I just use Rust: there is zero reason to deal with a garbage collector today. If I'm in C, it's because I care about predictable performance, and why I'm not using Java for that particular project.
https://docs.rs/gc/latest/gc/
Earlier quoted context omitted.
Because about 99% of the time the garbage collect is a negligible portion of your runtime at the benefit of a huge dollop of safety. People really need to stop acting like a garbage collector is some sort of cosmic horror that automatically takes you back to 1980s performance or something. The cases where they are unsuitable are a minority, and a rather small one at that. If you happen to live in that minority, great…
I think these threads attract people that write code for performance-critical use cases which explains the "cosmic horror" over pretty benign things. I agree though: most programs aren't going to be brought to their knees over some GC sweeps every so often.
Earlier quoted context omitted.
Why would I want to run a garbage collector and deal with it's performance penalties?
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.
Basically java gc is a solution to a problem that shouldn't exist.
Earlier quoted context omitted.
> very exotic requirements I'd be interested to know what you are thinking. The primary exotic thing I can imagine is an architecture lacking the ability to do atomic operations. But even in that case, C11 has atomic operations [1] built in. So worst case, the C library for the target architecture would likely boil down to mutex operations. [1] https://en.cppreference.com/w/c/atomic.html
Well, basically, yeah, if your platform lacks support for atomics, or if you'd need some extra functionality around the shared pointer like e.g. logging the shared pointer refcounts while enforcing consistent ordering of logs (which can be useful if you're unfortunate enough to have to debug a race condition where you need to pay attention to refcounts, assuming the extra mutex won't make your heisenbug disappear), o…
Earlier quoted context omitted.
> Because about 99% of the time the garbage collect is a negligible portion of your runtime In a system programming language?
Yes, plenty have been done already so since Lisp Machines, Smalltalk, Interlisp-D, Cedar, Oberon, Sing#, Modula-2+, Modula-3, D, Swift,.... It is a matter to have an open mindset. Eventually system languages with manual memory management will be done history in agentic driven OSes.