So apparently, there are garbage collectors for C and C++. How the fuck do they work...

Reference counting is not garbage collection.

you replace allocation functions with gc libraries and delete free functions. it does the rest.

If your garbage collector can be added at compile-time, there is no problem.

If we restrict a possible system to only have a runtime presence, we have a few options.

Check out the Valgrind paper for an idea of how this can be accomplished.

I remember needing to write a garbage collector in C for uni, so it's not surprising that someone made a real version

github.com/orangeduck/tgc/blob/master/README.md

The only actual answer in this post.

what a total bs. heap allocated objects can be anywhere, stack, heap ... and there will be more as the program runs. have you actually read anything about gc?

You replace malloc and free with your own. The stack doesn't need to be garbage collected.

first of thats not what you wrote fag. scanning memory to find heap allocated objects is plain stupid.

second, if a local variable holds the heap allocated object, pointer is in stack not in heap.

third, you dont need to change free, you need to delete those.

sorry child you need to learn how to communicate first before anyone will take you seriously. please ask your guardian to review that post and try again

It looks at each word of the object and checks if it's a valid heap address. If so, it conservatively assumes that's a pointer. You can get false positives obviously, as well as false negatives if you do crazy shit like xor linked lists

this
it appears most people here don't understand how the heap and stack actually work

well it's kind of garbage collection if you write free calls in a destructor
it's just not automatic garbage collection

Hmmm. Are things always word-aligned?

RAII is not GC

You can force them to be unless the platform won't allow it.

That's neat.

rust

smart pointer are kind of GC called reference counting google it nigger :p

I've been lurking Jow Forums for years but first time I remember being this disappointed.
I understand if this is reddit or whatever you claim things that you don't have any idea about.
but this is a fucking anonymous board, wtf do you gain?

How stupid is scanning memory and looking for data that can be a valid heap address,
and finding each reference. Do you have any idea how unreliable this method is and how
inefficient scanning all memory to find data that looks like heap address, and then use all of
your "addresses" to find references?

The only way of doing GC is compiling with a GC library, replacing malloc/calloc/realloc to
GC versions, and deleting free calls.

It would be possible to hook allocation functions and free function to do that at run-time, but
it would be stupid.

And I don't know all these brainlets are he same fag who praise the wrong answer or different
anons, but that's just disappointing.

Pointers are word-aligned by default. So, if some struct field really does contain a pointer, it'll normally start on a word boundary.

The well-known Boehm GC library works exactly as described in those two posts, you moron.

>Do you have any idea how unreliable this method is
Mark-sweep is perfectly reliable, if you know the locations of all the pointer fields in all the objects (as is the case on the JVM, for example). Turns out, it's still pretty reliable without that information ("conservative GC", like Boehm GC, which works for C/C++ with no GC-specific compiler extensions).

>The only way of doing GC is compiling with a GC library, replacing malloc/calloc/realloc to GC versions, and deleting free calls.
Boehm GC does this. That's what "Track heap-allocated objects" means.

you still don't get do you?

>The garbage collector works with most unmodified C programs, simply by replacing malloc() with GC_MALLOC() calls, replacing realloc() with GC_REALLOC() calls, and removing free() calls.
en.wikipedia.org/wiki/Boehm_garbage_collector

It doesn't scan memory to look for data that may look like heap address, it records all the allocations because the allocations made by it's fucking functions already.

what I say UNRELIABLE is not mark&sweep. It's scanning memory to look for data that may be heap address, how can you decide if something is data or address, pro tip you can't.

even if you could, scanning all the heap and stack continuously to find addresses that """looks""" like heap address and finding references to each others would be extremely INEFFICIENT.

enough of this gc bullshit!
constexpr auto NaN = std::numeric_limits::signaling_NaN();
std::set set{};
for (int i{}; i < 100; i++)
set.insert(NaN);

std::unordered_set u_set{};
for (int i{}; i < 100; i++)
u_set.insert(NaN);

std::cout

This is so fucked up, imagine doing this shit instead of picking a real GC language.

also, lol @ C performance - the moment you need something high level you find the syntax just won't allow you to do it efficiently

fuck C, it's fucking cancer
just look at GTK - it's slower than javascript

From your own source:
>the Boehm–Demers–Weiser garbage collector ... is a conservative garbage collector
>It can take advantage of type information to locate pointers if such information is provided, but it is usually used without such information.
And, from en.wikipedia.org/wiki/Tracing_garbage_collection#Precise_vs._conservative_and_internal_pointers
>Conservative collectors assume that any bit pattern in memory could be a pointer if, interpreted as a pointer, it would point into an allocated object.

How does it check references on the stack?

>even if you could, scanning all the heap and stack continuously to find addresses that """looks""" like heap address and finding references to each others would be extremely INEFFICIENT.

You're right that it adds overhead, but it's really not as bad as you're suggesting.

hboehm.info/gc/04tutorial.pdf

This library is actually used to implement GC in Mono.

C is not fit for retained/event-based gooeys. Take a look at immediate mode toolkits.

Wtf is immediate mode, like, refreshing everything at once, like, opengl-style? Yeah, thanks, I'm not running a game loop in a normal app.

Also, to add, in several benchmarks (some included in those slides) this approach outperforms explicit malloc() and free().

Many JVM stacks have a maximum size of 1MB or less - implying a collection at max stack pressure only looks at ~125k candidate-pointers with the most naive implementation. In practice, a few clever observations mean that this worst-case behavior is never experienced.

If you don't believe this argument, check out the users of BDW: hboehm.info/gc/

C with BDW GC easily outperforms Java in those slide's benchmarks.