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

Giving C a superpower: custom header file (safe_c.h)

hwisnu.bearblog.dev

Post reply on HN
Print view View original

81–90 of 277 posts

Re: Giving C a superpower: custom header file (safe_c.h)

#81

Post by ksherlock »

cassepipe wrote: post #53
fuhsnn wrote: post #23

> C23 gave us [[cleanup]] attributes C23 didn't introduce it, it's still a GCC extension that needs to be spelled as [[gnu::cleanup()]] https://godbolt.org/z/Gsz9hs7TE

It is surprisingly hard to find information about it, do you have any ? From what I can guess it's a new syntax but it's the feature itself is still an extension ?

[[ ]] attributes were added in C++11 and later C23. There are 7 standard(C32) attributes but GCC has hundreds of them.

https://en.cppreference.com/w/c/language/attributes.html

https://en.cppreference.com/w/cpp/language/attributes.html

https://gcc.gnu.org/onlinedocs/gcc/Attributes.html

https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attribute...

Re: Giving C a superpower: custom header file (safe_c.h)

#82

Post by dboon »

Nice, but if the intention is portability my experience has unfortunately been that you pretty much have to stick to C99. MSVC’s C compiler is rough, but pretty much necessary for actual cross platform. I have my own such header which has many, many things like the OP’s. As much as I would find it constantly useful, I don’t have a cleanup utility because of this.

But if you can stay out of MSVC world, awesome! You can do so much with a few preprocessor blocks in a header

Re: Giving C a superpower: custom header file (safe_c.h)

#83

Post by Maxatar »

dboon wrote: post #82

Nice, but if the intention is portability my experience has unfortunately been that you pretty much have to stick to C99. MSVC’s C compiler is rough, but pretty much necessary for actual cross platform. I have my own such header which has many, many things like the OP’s. As much as I would find it constantly useful, I don’t have a cleanup utility because of this. But if you can stay out of MSVC world, awesome! You ca…

MSVC now supports C17.

Re: Giving C a superpower: custom header file (safe_c.h)

#84

Post by Dwedit »

dboon wrote: post #82

Nice, but if the intention is portability my experience has unfortunately been that you pretty much have to stick to C99. MSVC’s C compiler is rough, but pretty much necessary for actual cross platform. I have my own such header which has many, many things like the OP’s. As much as I would find it constantly useful, I don’t have a cleanup utility because of this. But if you can stay out of MSVC world, awesome! You ca…

That's the nice thing about macros, you can also have the macro generate C++ code using destructors instead of using the cleanup attribute. As long as your other C code is also valid C++ code, it should work.

Re: Giving C a superpower: custom header file (safe_c.h)

#85

Post by [deleted] »

_vqpz wrote: post #48
krapht wrote: post #2

C++: "look at what others must do to mimic a fraction of my power" This is cute, but also I'm baffled as to why you would want to use macros to emulate c++. Nothing is stopping you from writing c-like c++ if that's what you like style wise.

>Nothing is stopping you from writing c-like c++ if that's what you like style wise. You'll just have to get used to the C++ community screaming at you that it's the wrong way to write C++ and that you should just use Go or Zig instead

[deleted]

Re: Giving C a superpower: custom header file (safe_c.h)

#87

Post by zozbot234 »

sesm wrote: post #77
762236 wrote: post #35

Earlier quoted context omitted.

Why would I want to run a garbage collector and deal with it's performance penalties?

IDK about Fil-C, but in Java garbage collector actually speeds up memory management compared to C++ if you measure the throughput. The cost of this is increased worst-case latency. A CLI tool (which most POSIX tools are) would pick throughput over latency any time.

You also pay for the increased throughput with significant memory overhead, in addition to worst-case latency.

Re: Giving C a superpower: custom header file (safe_c.h)

#88

Post by goalieca »

cogman10 wrote: post #45
kouteiheika wrote: post #40

Earlier quoted context omitted.

> the shared pointer implementation uses a POSIX mutex [...] C++’s shared pointer has the same problem It doesn't. C++'s shared pointers use atomics, just like Rust's Arc does. There's no good reason (unless you have some very exotic requirements, into which I won't get into here) to implement shared pointers with mutexes. The implementation in the blog post here is just suboptimal. (But it's true that C++ doesn't ha…

> very exotic requirements I'd be interested to know what you are thinking. The primary exotic thing I can imagine is an architecture lacking the ability to do atomic operations. But even in that case, C11 has atomic operations [1] built in. So worst case, the C library for the target architecture would likely boil down to mutex operations. [1] https://en.cppreference.com/w/c/atomic.html

Which platforms might that be? Even MIPS has atomics (at least pointer sized last i checked).

Re: Giving C a superpower: custom header file (safe_c.h)

#89

Post by greenavocado »

762236 wrote: post #60
jerf wrote: post #52

Earlier quoted context omitted.

Because about 99% of the time the garbage collect is a negligible portion of your runtime at the benefit of a huge dollop of safety. People really need to stop acting like a garbage collector is some sort of cosmic horror that automatically takes you back to 1980s performance or something. The cases where they are unsuitable are a minority, and a rather small one at that. If you happen to live in that minority, great…

For new projects, I just use Rust: there is zero reason to deal with a garbage collector today. If I'm in C, it's because I care about predictable performance, and why I'm not using Java for that particular project.

https://docs.rs/gc/latest/gc/

Re: Giving C a superpower: custom header file (safe_c.h)

#90

Post by jnwatson »

khaledh wrote: post #32

The problem with macro-laden C is that your code becomes foreign and opaque to others. You're building a new mini-language layer on top of the base language that only your codebase uses. This has been my experience with many large C projects: I see tons of macros used all over the place and I have no idea what they do unless I hunt down and understand each one of them.

Like the Linux kernel?

Macros are simply a fact of life in any decent-sized C codebase. The Linux kernel has some good guidance to try to keep it from getting out of hand but it is just something you have to learn to deal with.

Post reply on HN