gistfile1.txt

fn decCountInc(self: ?*SnekObject, allocator: std.mem.Allocator) void {
        if (self == null) {
            return;
    }
        self.?.referenceCount -= 1;
        if (self.?.referenceCount == 0) {
            SnekObject.refCountFree(self.?, allocator);
        }
        
 }


test "testing decrement ref count" {
    const allocator = std.testing.allocator;
    const x = SnekObject.newSnekInteger(allocator, 1);
    try expect(x.?.referenceCount == 1);
    SnekObject.refCountInc(x);
    SnekObject.decCountInc(x, allocator);
    try expect(x.?.referenceCount == 1);
    SnekObject.decCountInc(x, allocator);
    // If I call this multiple times after this like this
  SnekObject.decCountInc(x, allocator);
  SnekObject.decCountInc(x, allocator);
// This will result in Segfault
}

and why would you need to allow for the pointer to SnekObject to be optional? there would be no need to call that function at all, and that can be checked before using the decCountInc function.

I'd change it to this instead:

fn decCountInc(self: *SnekObject, allocator: std.mem.Allocator) void {
    self.referenceCount -= 1;
    if (self.referenceCount == 0) {
        self.refCountFree(allocator);
    }
}

Are you sure you want to decrement below zero? That would be I bug, depending on your implementation.

I'd guard against it like this:

const std = @import("std");

fn decCountInc(self: *SnekObject, allocator: std.mem.Allocator) void {
    // decCountInc should never be called when referenceCount is already zero
    std.debug.assert(snekObj.referenceCount > 0); // error in debug and release safe

    self.referenceCount -= 1;
    if (self.referenceCount == 0) {
        self.refCountFree(allocator);
    }
}

Then you can call the function like this:

var snekObject: SnekObject = // ... some code returning a struct of type SnekObject

// ... use snekObject and increase the referenceCount
snekObject.refCountInc();

// ... do something else

// release it when done
snekObject.decCountInc();

Anyway, if you implement a init/deinit pattern instead, you can avoid reference counting and possible bugs (unless you're studying how to implement a reference count for learning purposes)

Thank you for your response and recommendations

Yes I am making a mini garbage collector in Zig by implementing the Reference Count and Mark and Sweep algorithms

I want to check that the object I allocated on heap is freed or not properly in my tests
So I was experimenting with the optionals to the pointer to see after freeing the object would It make the pointer null or not but I think it does not, I can be wrong though.

Also yes I think the init and deinit pattern is clean and I think most of the time it works and by that we can avoid passing the allocator repeatedly which can be tedious.

Is there anyway to check that a particular object which was allocated on the heap is freed or not

Freeing memory will never make your pointers null. There are bugs such as “double free” or memory corruption when keeping pointers to memory that was freed

You can’t easily check if an “object” was freed or not AFAIK (I mean if the pointer is still valid). You could implement your own allocator if you need that information but that’s a bit extreme.
Usually the init / deinit pattern helps with remembering to always free after use (and not free twice or avoid using the freed memory after free).

Usually you think about ownership of which part of the code handles the resource allocation, moves ownership and then the owner has to handle free.
With implementing a garbage collection and reference counting that’s the difficult part as there’s no clear owner of the object being passed around freely.

Not sure how I would implement a check if it’s freed or not. I think you could just free only when you decrement from 1 to 0, but remember to always add 1 when using the object and remove 1 when you’re done.

The function doing the allocation will move ownership to the caller hence it should pre-increment 1 (that way you can check it’s not zero which is not freed yet)

Thank you @Zorgatone
This is really helpful