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

151–160 of 174 posts

Re: Stupid Smart Pointers in C

#151

Post by DanielHB »

hn_acc1 wrote: post #117
DanielHB wrote: post #88

Earlier quoted context omitted.

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..

It is not that bad, the code is easier than your average web server and it is usually only one CPU for consumer devices. It gets bad if:

1) You add embedded linux

2) You have multiple CPUs that need to communicate with each other.

3) Both of the above (then the complexity skyrockets)

(this happens in modern cars)

So basically if it has a full LCD display (instead of 7-segment with a few extra toggle lights) I don't buy it.

It is actually quite refreshing code to read and write, yes the quality is often bad, but it often feels like school projects where they are small enough you can hold the complete system in your head. And it usually doesn't integrate with anything else besides the eletronics in the board

Re: Stupid Smart Pointers in C

#152

Post by lionkor »

> Managing memory in C is difficult and error prone. C++ solves this with smart pointers like std::unique_ptr and std::shared_ptr.

No, it does not. Smart pointers are useful to help model lifetimes and ownership, but the real killer feature is RAII. Add that to C (standardized) and you can make smart pointers, and any other memory management primitive you need. Smart pointers are not a solution, they are one of many tools enabled by RAII.

Re: Stupid Smart Pointers in C

#153

Post by lionkor »

ForTheKidz wrote: post #138
casenmgreen wrote: post #107

I maintain a combined error and resource state per thread. It is first argument to all functions. If no errors, function proceeds - if error, function instead simply immediately returns. When allocating resource, resource is recorded in a btree in the state. When in a function an error occurs, error is recorded in state; after this point no code executes , because all code runs only if no errors. At end of function i…

Why bother freeing before exit?

Assuming that this would include properly closing sockets, etc. which the OS doesn't do the same way you might want to

Re: Stupid Smart Pointers in C

#154

Post by TickleSteve »

dietr1ch wrote: post #64
DanielHB wrote: post #34

Earlier quoted context omitted.

There are quite a lot of embedded code that relies on obscure C compilers created and maintained by the CPU manufacturer. But then again you are probably not doing a whole lot of heap management in embedded code.

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.

static allocation is the recommended mechanism in embedded code for reliability reasons, you have thought about you worst-case allocation and accounted for it... right? Also fragmentation and dynamic behaviour are bad things when your code has to run "forever".

Re: Stupid Smart Pointers in C

#155

Post by bsenftner »

julietto wrote: post #150
jcranmer wrote: post #52

Earlier quoted context omitted.

We have 50 years of experience of code telling us that, no, programmers are not consistently capable of avoiding memory safety just by being good about it. Saying that it's just a failing of lesser programmers is the height of extreme arrogance, since I guarantee you that you've written memory safety vulnerabilities if you've written any significant amount of C code. The problem is not that the rules are hard to foll…

The solution to that is to either: 1) If you're gonna return pointers, don't use an allocation scheme that invalidates pointers in the implementation of map_t. 2) If you want to reallocate and move memory, don't return pointers, return abstracted handles/indices. Both of those are completely possible and not particularly unergonomic to do in C. If you need to enforce invariants, then enforce them, C does have enough…

Handles for the win, I never understood why we don't use handles for all dynamic memory.

Re: Stupid Smart Pointers in C

#156

Post by WalterGillman »

masklinn wrote: post #37
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/…

> we hope will be added to the C spec one day defer seems to be making significant progress (having a passionate and motivated advocate in Meneide, and a full TS)

Was just reading about this one the other day. Well-defined behavior and it actually solves a problem. Conceptually, I can't say it is worse than variadic functions or setjmp.

Re: Stupid Smart Pointers in C

#157

Post by torlok »

dima55 wrote: post #130
torlok wrote: post #104

Earlier quoted context omitted.

I've heard enough "C is superior to C++" arguments from game developers who then go and use header structs for inheritance, or X macros, enums, and switch statements for virtual functions, to know that more complexity isn't an issue as long as people feel clever and validated.

X macros can do tons of stuff C++ can't. And if you stick with C, you avoid mountains of C++ problems, even with all the stuff you're talking about.

I never said X macros are bad on their own. With C++ you can code exactly as you would in C, but you don't have to manually implement C++ features when there's a need. C++ doesn't have any more problems than C, it's programmers who abuse language features that creates problems.

Re: Stupid Smart Pointers in C

#158

Post by heftig »

zabzonk wrote: post #145
wavemode wrote: post #120

Earlier quoted context omitted.

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

simply checking for NULL doesn't allow that - for example for something that might have been opened with fopen() needs to be closed with fclose() rather than free(), and you can't tell that from the pointer.

I think the implication was that they're pointers to objects that own resources (like containing FILE handles) and need to be "freed" with a custom function, not just "free".

    void my_thing_free(MyThing *thing) {
        fclose(thing->file);
        free(thing);
    }
assuming an associated "my_thing_new" that only returns a valid pointer when both the allocation and the fopen succeeded.

Re: Stupid Smart Pointers in C

#159

Post by epolanski »

devit wrote: post #131

That's completely asinine since it can't be made to work properly with inlining (including LTO), architectures that use a shadow stack or don't use a frame pointer, and also ridiculously inefficient and requiring assembly code for all architectures. Use C++ or __attribute__((cleanup)) instead.

Maybe it is.

Or maybe the asinine "thing", is some folks lack of text comprehension skills that can't distinguish an experiment from a best practice recommendation despite a title and content that clearly does not invite that.

Post reply on HN