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

21–30 of 174 posts

Re: Stupid Smart Pointers in C

#21

Post by rwmj »

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.

It's so widely used by OS software that you're likely using already, that it's unlikely to be removed and much more likely to be standardized. This is in fact how standardization ought to work - standardize the proven best practices.

Re: Stupid Smart Pointers in C

#22

Post by afarah1 »

See also the "arena allocator", which has been discussed here before: https://nullprogram.com/blog/2023/09/27/

I haven't used it personally yet, but it addresses the same issue with a different approach, also related to stack-like lifetimes.

I've used simple reference counting before, also somewhat relevant in this context, and which skeeto also has a nice post about: https://nullprogram.com/blog/2015/02/17/

Re: Stupid Smart Pointers in C

#23

Post by bsenftner »

empath75 wrote: post #18
bsenftner wrote: post #6

[flagged]

Why do you use pointers and a high level language like C when you could just write assembly and load and unload all your instructions and data into registers directly. Why do you need functions? You could just use nothing but JMP instructions. There's a whole lot of stuff that C handles for you that is completely unnecessary if you really understood assembly and paid attention to what you're doing.

I'm from the era that when I was taught Assembly, half way through the class we'd written vi (the editor), and when finishing that one semester we had a working C compiler. When I write C, I drop into Assembly often, and tend to consider C a macro language over Assembly. It's not, but when you really understand, it is.

Re: Stupid Smart Pointers in C

#24

Post by maccard »

rwmj wrote: post #21
maccard wrote: post #16

Earlier quoted context omitted.

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

It's so widely used by OS software that you're likely using already, that it's unlikely to be removed and much more likely to be standardized. This is in fact how standardization ought to work - standardize the proven best practices.

I agree. But if we follow that logic then any compiler specific feature of either or clang is fair game, even if it’s not standard. MSVC doesn’t support it when compiling in C mode, for example.

Re: Stupid Smart Pointers in C

#25

Post by empath75 »

bsenftner wrote: post #23
empath75 wrote: post #18

Earlier quoted context omitted.

Why do you use pointers and a high level language like C when you could just write assembly and load and unload all your instructions and data into registers directly. Why do you need functions? You could just use nothing but JMP instructions. There's a whole lot of stuff that C handles for you that is completely unnecessary if you really understood assembly and paid attention to what you're doing.

I'm from the era that when I was taught Assembly, half way through the class we'd written vi (the editor), and when finishing that one semester we had a working C compiler. When I write C, I drop into Assembly often, and tend to consider C a macro language over Assembly. It's not, but when you really understand, it is.

And Rust developers drop down and manage memory directly when they need to and even inline assembly, sometimes.

Re: Stupid Smart Pointers in C

#26

Post by [deleted] »

bsenftner wrote: post #19
jraph wrote: post #13

Earlier quoted context omitted.

I guess you are "the one". This means you won't fail this stuff and this discussion is not for you, it is for the rest of us who would. https://rachelbythebay.com/w/2018/04/28/meta/

I'm advocating not to wing it, design up front and then follow that design. When the design is found lacking, redesign with the entire system in mind. Basically, all I'm saying is do not take short cuts, they are not short cuts. Your project may finish faster, but you are harming yourself as a developer.

[deleted]

Re: Stupid Smart Pointers in C

#28

Post by nottorp »

empath75 wrote: post #25
bsenftner wrote: post #23

Earlier quoted context omitted.

I'm from the era that when I was taught Assembly, half way through the class we'd written vi (the editor), and when finishing that one semester we had a working C compiler. When I write C, I drop into Assembly often, and tend to consider C a macro language over Assembly. It's not, but when you really understand, it is.

And Rust developers drop down and manage memory directly when they need to and even inline assembly, sometimes.

Yes we know, all the world's problems can be solved with a rewrite in Rust.

Andre Malraux was right: "The 21st century will be religious or it will not be".

He just got the definition of religion wrong.

Re: Stupid Smart Pointers in C

#29

Post by dietr1ch »

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.

> relying on compiler vendor extensions kind of defeats the purpose of that.

Let's be honest, how many compilers are available, and how many of those would you actually use?

The answer isn't more than 4 and the 2 compilers you are most likely to use among those already support this and probably won't stop supporting without a good alternative.

I like standardisation, but you have to be realistic when it helps you without a large real cost other than fighting your ideals for getting this into the standard first.

Re: Stupid Smart Pointers in C

#30

Post by fuhsnn »

usrnm wrote: post #20
scoopr wrote: post #7

Oh well, maybe we'll soon have `defer`? [0] [0] https://thephd.dev/c2y-the-defer-technical-specification-its...

That's sad. Having migrated from C++ to golang a few years ago, I find defer vastly inferior to C++ destructors. Rust did it right with its drop trait, I think it's a much better approach

The proposed C defer is scope-based unlike Go. So in the spirit of OP article, you can basically hand roll not only C++ destructor as defer {obj.dtor()} but also Rust Drop as defer {obj.notmoved() ? Drop()}
Post reply on HN