Smart Pointers in (GNU) C

GLib also provides macros that use autocleanup.[0]<p>Using a bunch of macro magic, they allow you to write `g_autoptr(GPtrArray) arr = ...` to automatically unref arr when the scipe exits. One footgun that autocleanup has and C++ smart pointers don&#x27;t is, that the cleanup function isn&#x27;t called on reassignment, so reassigning on a autoptr causes the previous value to leak.<p>[0]:<a href="https:&#x2F;&#x2F;docs.gtk.org&#x2F;glib&#x2F;auto-cleanup.html" rel="nofollow">https:&#x2F;&#x2F;docs.gtk.org&#x2F;glib&#x2F;auto-cleanup.html</a>

I think the desire for smart pointers comes from having many allocations of various lifetimes. In my opinion smart pointers are a band-aid at too low a level to solve this problem. In C++ this seems particularly attractive because it is very common to consider freeing memory and uninitializing memory to be the same thing and handle both with RAII.<p>C becomes much more bearable and even ergonomic when introducing multiple allocators, especially an arena. This reduces the amount of separate allocations and lifetimes dramatically. A big failure of the C standard library in my opinion is that it does not offer such allocators and the APIs don’t make use of them (which is why strings are terrible in C).

&gt; This sucks, but if we make the assumption that no destruction shall happen during an async context, it’s kind of fine (Oh boy, this will definitely make people jump out of their seat). On a side note, I have yet to see a proper solution to that, and I would like to avoid having double pointed types to solve the issue – if anyone has an idea, feel free to send me a message or send a pull request on the github repository.<p>An async context marks pointers to destroy rather than destroy them immediately (defer destruction by unqueueing them), and a dedicated thread periodically wakes and processes the queue of marked objects. It must should be processed on another thread because the object is by definition no longer reachable from the original thread since it&#x27;s marked for destruction.

Basically a wrapper for &quot;__attribute__(cleanup)&quot;<p>GCC took the best C++ feature (destructors) and added it into C. Not sure about compatibility with other C compilers.

Strong vibes of Greenspun&#x27;s tenth rule:<p>Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.<p>If you want garbage collection, use a language that has it.

Worth noting that the metadata structure can be done more efficiently with a flexible array member, but it requires alignment to alignof(max_align_t) to obey the ABI. The structure will consume the same amount of memory (16 bytes on x86-64) but you avoid a dereference and you have an extra pointer worth of space to use for whatever.

(2015) or earlier

it&#x27;s great when the ratio of cmake to C is close to 3...

It is time to reply to the issues that were posted since these years...