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

My personal C coding style as of late 2023

nullprogram.com

Post reply on HN
Print view View original

321–330 of 466 posts

Re: My personal C coding style as of late 2023

#321

Post by harpiee »

uxp8u61q wrote: post #289
sebastianz wrote: post #280

Earlier quoted context omitted.

> it came with all the batteries included Sometimes you do not want, or need, all the batteries.

Smart pointers alone make the switch worth it. Why wouldn't you want that?

Smart pointers for what?

I don't use any dynamically allocated memory in my firmware projects.

I do sometimes use statically allocated pools for things like packet buffers and allocate chunks out of them, but their lifetimes are not scope based, so automatic call of constructors/destructors would not be of any help.

Re: My personal C coding style as of late 2023

#322

Post by Pathogen-David »

stephc_int13 wrote: post #261

One nice thing about short types (i32 f32 u16 etc.) is that they can easily be extended for vector types such as f32x4 or u8x16 etc. Consistency, conciseness and clarity (you don't have to guess much about those, once you've understood the naming scheme)

I actually have the opposite feeling. I like the non-sized type names like float extended as float4 or float4x4.

My brain wants to read f32x4 as a 32 by 4 matrix of floats.

(That being said I'd definitely be interested in trying your convention in the context of something like Rust.)

Re: My personal C coding style as of late 2023

#323

Post by richard_todd »

seanw444 wrote: post #304
WalterBright wrote: post #164

Earlier quoted context omitted.

> carrying bit length in the name is critical I beg to disagree. In D: byte - 8 bits short - 16 bits int - 32 bits long - 64 bits absolutely nobody is confused about this.

When we move into the 128-bit CPU era, will we call 128-bit integers "super long"? Maybe "elongated". Maybe "huge"? Or, you know, we could just name them all by bit length and completely future-proof this system.

We used to call 16-bytes a paragraph, so the nostalgic geek in me would love to see ‘para’ catch on. I never thought I’d be slinging around whole paragraphs of memory in registers!

Re: My personal C coding style as of late 2023

#324

Post by jpcfl »

glitchc wrote: post #85
jpcfl wrote: post #78

Parameters and functions No const. Please don't. `const` is incredibly valuable, not only to the reader, but to the compiler. Take for example: int Foo_bar(Foo const* self); Just looking at this signature, I know that calling `bar()` will not modify the state of the object. This is incredibly valuable information to the reader. Furthermore, if I want to create a `Foo` constant, I can only call this function if it is…

I'm afraid you are mistaken. In particular for pointers, const does not guarantee that the memory at the location pointed to won't change. Const only guarantees that the address itself doesn't change.

> const does not guarantee that the memory at the location pointed to won't change

I didn't say this. I said a `const` function tells the reader that the state of an object doesn't change.

Another reader correctly pointed out that there are ways to modify the state of a `const` parameters (indirection and const cast), but I would argue that such an API is poorly-designed.

To qualify my original comment, a reader only knows a function doesn't change an object's state if the API is well-designed.

Re: My personal C coding style as of late 2023

#325

Post by beeforpork »

Pathogen-David wrote: post #320
beeforpork wrote: post #301

Hopefully I never need to review code written with these definitions. It's an awful idea to do this. The first section shows why some languages have no 'typedef': introducing another layer of aliases is just not a good idea. It's confusing, it changes the appearance to basically a new language. Just use the standard names, instead of redefining your language, like everyone else. This style is almost as bad as '#defin…

> As a side note, I don't understand the #define for sizeof. Their `size` type is signed. It's `ptrdiff_t`, not `size_t`.

Ah, thanks! So code will look normal, but be subtly different. This is even worse than I thought!

Re: My personal C coding style as of late 2023

#327

Post by stephc_int13 »

Pathogen-David wrote: post #322
stephc_int13 wrote: post #261

One nice thing about short types (i32 f32 u16 etc.) is that they can easily be extended for vector types such as f32x4 or u8x16 etc. Consistency, conciseness and clarity (you don't have to guess much about those, once you've understood the naming scheme)

I actually have the opposite feeling. I like the non-sized type names like float extended as float4 or float4x4. My brain wants to read f32x4 as a 32 by 4 matrix of floats. (That being said I'd definitely be interested in trying your convention in the context of something like Rust.)

float4 is nice, but in video games, especially graphics, the vast majority of our floats are 32 bits but we also use 16 bits floats quite extensively, and in this case it is quite practical to follow the same convention. f32 -> f16 f32x4 -> f16x4

And when working on some heavily optimized SIMD code on the CPU side, I tend to use the default types even less.

Re: My personal C coding style as of late 2023

#328

Post by jpcfl »

david2ndaccount wrote: post #81
jpcfl wrote: post #78

Parameters and functions No const. Please don't. `const` is incredibly valuable, not only to the reader, but to the compiler. Take for example: int Foo_bar(Foo const* self); Just looking at this signature, I know that calling `bar()` will not modify the state of the object. This is incredibly valuable information to the reader. Furthermore, if I want to create a `Foo` constant, I can only call this function if it is…

You only know there are no mutations if Foo itself does not contain any indirections. Additionally, the compiler generally cannot assume that Foo_bar does not modify Foo as it is legal to cast away const as long as it is not originally a variable declared as const (so in your static Foo example it would be UB to cast away const). static + const is valuable, but const parameters are merely a convention, there is no ac…

True. I should rephrase to say `const` strongly suggests that a function does not change the observable state of a variable.

Re: My personal C coding style as of late 2023

#329

Post by stephc_int13 »

WalterBright wrote: post #163
Uptrenda wrote: post #84

IMO, defining your own types is one step too far. Now everyone who is already familiar with C types has to learn your own quirky system to understand one program. I think it does probably make sense to be specific about the sizes though e.g. using uint32_t over just uint (and expecting to receive some architecture-dependent size you might not get with uint.) These types should be defined in the right header (I think…

The reality is that C `int` is 32 bits in size. Sure, that's not true for 16 bit targets. But are you really going to port a 5Mb program to 16 bits? It's not worth worrying about. Your code is highly unlikely to be portable to 16 bits anyway. The problem is with `long`, which is 32 bits on some machines and 64 bits on others. This is just madness. Fortunately, `long long` is always 64 bits, so it makes sense to just…

Long Long is ridiculous and often confusing.

Now, what about SIMD types?

What about 16bits floats?

Using the short size convention we have easy and logical answers.

The reason why new languages like Rust and Zig are using those conventions is not random, types naming (and stdlib) is a weak point of C (and C++).

Luckily they are not set in stone, we can choose different and reasonable conventions.

Re: My personal C coding style as of late 2023

#330

Post by i_am_a_peasant »

galangalalgol wrote: post #299
colejohnson66 wrote: post #286

Earlier quoted context omitted.

Not sure about 64-bit `int`, but it is 16-bit on some 16-bit micros, such as the AVR line (used by the original Arduino).

Ti dsps have 48bits for long.

yeah i had 48 bit pointers on one asic. upper 16 bits selected memory partition/region
Post reply on HN