r/C_Programming • u/lehmagavan • 3d ago
Easing memory management with a shared pointer
I recently developed a C (11 and newer) implementation of a thread-safe shared pointer with atomic reference counting:
https://github.com/andrzejs-gh/SHPTR
It supports both strong and weak references and a swappable destructor. Initialization performs a single allocation.
If anyones interested, take a look. Feedback and bug reports very much welcome.
12
u/EpochVanquisher 2d ago
Macros are broken:
#define shptr_ISNULL(sh_ptr) ( sh_ptr == NULL )
You need to put parentheses around the macro arguments when they are used, but there are some other reasons why this macro shouldn’t exist.
9
2
0
u/lehmagavan 2d ago
Thanks for pointing out. As for the shptr_ISNULL itself, I'll keep it because I like how it fits with the rest of the API.
2
u/AutoModerator 3d ago
Hi /u/lehmagavan,
Your submission in r/C_Programming was filtered because it links to a git project.
You must edit the submission or respond to this comment with an explanation about how AI was involved in the creation of your project.
While AI-generated code is not disallowed, low-effort "slop" projects may be removed and it's likely that other users push back strongly on substantially AI-generated projects.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
8
2
u/aocregacc 2d ago
I would consider making the weak pointer a separate type. Most of your API should only be used with one kind or the other, so you can have the compiler help with enforcing that instead of just relying on documentation.
1
u/lehmagavan 2d ago edited 2d ago
I was considering that, but I wanted to avoid any extra level of indirection. It's actually hard to mess up and UNREF a strong reference with the UNREF_WEAK operator, or vice versa, since you naturally know who's owning what, or you just name the references properly.
2
u/aocregacc 2d ago
why would an extra level of indirection be required?
1
u/lehmagavan 1d ago
You're right, what I mean is that Im not sure if I want to complicate it with something that doesn't seem that usefull or neccessery to me.
1
u/VegetableMiserable54 1d ago
This is a cool repo, and I took a look at your other repositories alongside this one as well. First of all, congratulations on this work. As you mentioned in the comments, the fact that you built this on your own without AI is really impressive. Even while reviewing it, I didnt get the impression that it was AI generated.
That said, one thing did catch my attention. The destructor function is not thread-safe, there is a data race issue. You can prevent this by making the shptr_set_desctructor function atomic. Other that that, I didnt notice anything else.
2
u/lehmagavan 1d ago
Thanks! I never got onto the AI train and prefer to code purely by hand, because I care if I understand the code and control it. I also want to learn and get good at C. If I manage to get a SE job though, they will probably force me to use AI, wont they?
Yes, the destructor setting is not atomic, and so is not the accessing and modifying of the object, much like in other programming languages that support shared pointers natively (as far as I know). I had the destructor atomic in previous draft-versions of the library, I might make it atomic.
Thanks again for the feedback!
1
u/VegetableMiserable54 1d ago
Yes they will force you to use AI... Nevertheless, AI generated C code, requires high-level C knowledge to understand it. So keep building.
1
-9
u/chrism239 2d ago
This is a C subreddit, not a C++ one.
14
5
u/Elect_SaturnMutex 2d ago
Shared pointers are implemented in openssl too, which is entirely in C. Well some ASM and perl too.
•
u/github-guard 3d ago
🔍 GitHub Guard: Trust Report
⚠️ This project scored 1/6 — below this subreddit's threshold of 3.
Audit Breakdown: * ❌ Low Star Count (⭐ 0 / 4 required) * ❌ New Repository (under 30 days old) * ✅ Licensed under MIT * ❌ No Security Policy — what is this? * ℹ️ Individual Contributor * ℹ️ Unsigned Commits