Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stupid Smart Pointers in C

blog.kevinalbs.com

Post reply on HN
Print view View original

111–120 of 174 posts

Re: Stupid Smart Pointers in C

#111

Post by milesrout »

maccard wrote: post #16
rwmj wrote: post #5

Really, don't do this, it's a portability and safety nightmare (aside from C not being memory safe already). C programmers are better off with either of these two techniques: * Use __attribute__((cleanup)). It's available in GCC and Clang, and we hope will be added to the C spec one day. This is widely used by open source software, eg. in systemd. * Use a pool allocator like Samba's talloc ( https://talloc.samba.org/…

> It's available in GCC and Clang, and we hope will be added to the C spec one day. This is widely used by open source software, eg. in systemd. It’s odd that the suggestion for a feature lacking in C is to use a non standard but well used supported path. c’s main selling point (IMO) is that it _is_ a standard, and relying on compiler vendor extensions kind of defeats the purpose of that.

C's main selling point is not standardisation. It was widely used before standardisation and only standardised because it was useful.

Re: Stupid Smart Pointers in C

#112

Post by dhooper »

flohofwoe wrote: post #76

IMHO trying to emulate smart pointers in C is fixing a problem that shouldn't exist in the first place, and is also a problem in C++ code that uses smart pointers for memory management of individual objects. Objects often come in batches of the same type and similar maximum lifetime, so let's make use of that. Instead of tracking the individual lifetimes of thousands of objects it is often possible to group thousands…

This is the way

Re: Stupid Smart Pointers in C

#113

Post by legohead »

nine_k wrote: post #103
legohead wrote: post #77

Earlier quoted context omitted.

My C programs never consumed gigs of memory. So I (like many others I assume) made a memory manager and never freed anything. You'd ask it for memory and it kept a list of various sizes it allocated and returned what you needed to be re-used. Freeing and allocating is slow, and error prone, so just avoid it!

Well, it's basically an implementation of a memory allocator. But how did you determine what you could re-use? That's the hard problem, one that's equivalent to calling free() at the right time.

When something would normally be freed, it calls the memory manager's version of free(), which zeroes the memory and adds it back into the appropriate available list.

Re: Stupid Smart Pointers in C

#114

Post by PortiaBerries »

Around 1994, when I was a nerdy, homeschooled 8th grader teaching myself coding I came up with something I was inordinately proud of. I had gotten a book on PowerPC assembly so using Metrowerks CodeWarrior on my brand-new PowerMac 7100 I wrote a C function with inlined assembly that I called debugf. As I recall, it had the same signature as printf, called sprintf and then passed that resulting string to DebugStr. But the part I was proud of was that it erased itself from the stack so when the debugger popped up it was pointing to the line where you called debugf. I'm still proud of it :-).

Re: Stupid Smart Pointers in C

#116

Post by LegionMammal978 »

legohead wrote: post #113
nine_k wrote: post #103

Earlier quoted context omitted.

Well, it's basically an implementation of a memory allocator. But how did you determine what you could re-use? That's the hard problem, one that's equivalent to calling free() at the right time.

When something would normally be freed, it calls the memory manager's version of free(), which zeroes the memory and adds it back into the appropriate available list.

Isn't that just stacking your own allocator on top of the libc allocator, the same way the libc allocator is stacked on top of the OS's page mappings? It's often a sensible idea, of course, but I wouldn't describe it as "never freeing things", just substituting libc's malloc()/free() for your own. It's not like the libc allocator is doing something radically different from keeping lists of available and allocated memory.

Re: Stupid Smart Pointers in C

#117

Post by hn_acc1 »

DanielHB wrote: post #88
dietr1ch wrote: post #64

Earlier quoted context omitted.

That sounds like the kind of code that you want to be done with and never touch again. You can only dream of it not being buggy or catching up with the newest standard.

No it is more like the 10000 lines of code running in your washing machine, you will probably be updating it in the next year revision of the product. It is quite common for this code to have all variables be global and just not have any heap allocations at all. Sometimes you don't even have variables in the stack either (besides the globals).

I much prefer the purely-mechanical washing machines for this reason.. Way less to go wrong..

Re: Stupid Smart Pointers in C

#118

Post by knorker »

legohead wrote: post #113
nine_k wrote: post #103

Earlier quoted context omitted.

Well, it's basically an implementation of a memory allocator. But how did you determine what you could re-use? That's the hard problem, one that's equivalent to calling free() at the right time.

When something would normally be freed, it calls the memory manager's version of free(), which zeroes the memory and adds it back into the appropriate available list.

You're just describing every allocator in the world, except many (most?) skip the zeroing part.

libc already does that. What is it that yours is adding?

I'd say 25 years ago you could write your own naive allocator, make just a couple of assumptions for your use case, and beat libc. But no more.

One of the selling points of Java in the 90s was the compacting part. Because in the 90s fragmentation was a much bigger problem than it is today. Today the libc allocators have advanced by maybe tens of thousands of PhDs worth of theory and practice. Oh, and we have 64bit virtual address space, which helps with some (but not all) of the problems with memory fragmentation.

See this post from Ian Lance Taylor about why Go didn't even bother with a compacting GC: https://groups.google.com/g/golang-nuts/c/KJiyv2mV2pU?pli=1

Re: Stupid Smart Pointers in C

#120

Post by wavemode »

zabzonk wrote: post #101
mac3n wrote: post #92

this is way overkill the way i do this in C looks like initialize all resource pointers to NULL; attempt all allocations; if all pointers are non-NULL, do the thing (typically calling another routine) free all non-NULL pointers realloc(ptr, 0) nicely handles allocations and possible-NULL deallocations

might as well free the NULL pointers as well - this is totally valid C and can simplify the code

I suppose the implication is that, checking for null allows your cleanup logic to be more complex than simply calling free()

for example, the object could be managing an open file, or an open socket

Post reply on HN