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

351–360 of 466 posts

Re: My personal C coding style as of late 2023

#351

Post by sovande »

stephc_int13 wrote: post #329
WalterBright wrote: post #163

Earlier quoted context omitted.

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.

> Long Long is ridiculous and often confusing

It might be ridiculous, but it’s hardly confusing for a C programmer. But, yeah in and ideal world ‘long’ should just be defined as 64 bits

Re: My personal C coding style as of late 2023

#352

Post by ryandrake »

ultrarunner wrote: post #343
rurban wrote: post #257

Earlier quoted context omitted.

C is also used on embedded. It's even there the default language.

Yeah, almost the only time I'm writing C anymore is embedded, where I want to reason about type widths (while taking on as light a cognitive load as is possible). I have enough code that gets compiled to an 8, 16, or 32 bit target depending on context that having the bit width right on the tin is valuable. And it doesn't even cost me "hours and hours".

Also: Embedded is almost the only time you really, truly need to care about how many bits a type is, and only when you're interacting with actual hardware.

For almost every other routine task in programming, I would argue that it really doesn't matter if your int is 32 bits wide or 64 bits wide. Why go through the trouble of insisting on int32_t or int64_t? It probably doesn't matter for the things you are counting.

Some programmers will say "Well, we should use int64_t here because int32_t might overflow!" OK, so why weren't you checking for overflow if it was an expected case? int64_t might overflow too, are you checking after every operation? Probably not. "OK, let's use uint64_t then, now we get 2x as many numbers!" Now you have other overflow (and subtraction) problems to handle.

Nowadays, I just use int and move on with my life. It's one of those lessons from experience: "When I was younger, I used int and char because I didn't know any better. When I was older, I created this complex, elaborate type system because I knew better. Now that I'm wise, I just use int and char."

Re: My personal C coding style as of late 2023

#353

Post by seanw444 »

ogogmad wrote: post #339
seanw444 wrote: post #304

Earlier quoted context omitted.

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.

Why would we ever need 128-bit CPUs? I remember the PS2 had something like that (with details and caveats I don't understand), but subsequent games consoles went back to a more usual register size: https://en.wikipedia.org/wiki/128-bit_computing

All I know is we keep having this issue with saying "nah, this is it. Nobody will ever need more than this." And then inevitably the time comes when we need more.

Re: My personal C coding style as of late 2023

#354

Post by habibur »

kovacs_x wrote: post #279
habibur wrote: post #276

Earlier quoted context omitted.

In my case : - I prefer functions over classes. - no mangling of exported names, the binary is re-usable as API. - in the long term, the C source code is more re-usable in other projects than C++ ones. and more like this.

sure... and what about time spent debugging yet another unallocated/untimely freed/off by 1 pointer mistake? ps. you know you can write C++ code that is functional and use free functions primarily instead of putting everything in classes?

you can run valgrind and it will just point to you "you freed the memory on this line and then tried to reused it 10 lines bellow here, fix it." -- every time.

And once you fix it, you have built a light weight library that you can use from any other language.

Also these pointer manipulation is what gives C its power.

Re: My personal C coding style as of late 2023

#355

Post by mikewarot »

mhd wrote: post #349
mikewarot wrote: post #146

Earlier quoted context omitted.

>Pascal strings? Yeah, that’s probably the better call, but why not use C++ or Rust or something where a bunch of geniuses got it right already? I'll be diving into C fairly heavy for the first time ever next year. I intend to skip right past pascal strings and implement/use free pascal's AnsiString or UnicodeString, both of which are reference counted, have a length (with no limit) and are guaranteed null terminated…

Haven't seen that many refcounted string libraries for C in recent times, most common one is probably still the one from glib. I guess you're going to implement your from scratch, or is there some prior art you're likely to use?

If at all possible, I'll just lift the one from Free Pascal. Otherwise, it's yet another chore in the process of bringing MStoical (a modern port of the STOIC language) to life

Re: My personal C coding style as of late 2023

#356

Post by blix »

eviks wrote: post #236
drpixie wrote: post #92

Earlier quoted context omitted.

Well ... Name a language is which you categorically cannot "shoot yourself in the foot"!

The "categorically" part is a useless qualification, you don't program in a binary world, the ease with which a footgun is possible in a language is very important and can't be reduced to isPossible

I do most of my programming in a binary world.

Re: My personal C coding style as of late 2023

#357

Post by P_I_Staker »

adamrezich wrote: post #336
neilv wrote: post #216

> While I still prefer ALL_CAPS for constants, I’ve adopted lowercase for function-like macros because it’s nicer to read. "ALL_CAPS" in C was not for constants, but for preprocessor macros. It's shouting in all-caps, because it means "Look out! There's a cpp macro expansion here!" Related, please stop using "ALL_CAPS" for constants in other languages. Not only does shouting constants as the most prominent syntax in…

nah, sorry, I'm going to keep using ALL_CAPS_CONSTANTS (and enum members, because they're also constants). I like having constants be visually distinct from the rest of my code.

Yeah, I don't see the problem. I believe this is default for pylint, and I see no issue with convention.

Re: My personal C coding style as of late 2023

#358

Post by aidenn0 »

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…

I swear I've seen 128-bit "long long" types.

Re: My personal C coding style as of late 2023

#359

Post by terracottalite »

ryandrake wrote: post #352
ultrarunner wrote: post #343

Earlier quoted context omitted.

Yeah, almost the only time I'm writing C anymore is embedded, where I want to reason about type widths (while taking on as light a cognitive load as is possible). I have enough code that gets compiled to an 8, 16, or 32 bit target depending on context that having the bit width right on the tin is valuable. And it doesn't even cost me "hours and hours".

Also: Embedded is almost the only time you really, truly need to care about how many bits a type is, and only when you're interacting with actual hardware. For almost every other routine task in programming, I would argue that it really doesn't matter if your int is 32 bits wide or 64 bits wide. Why go through the trouble of insisting on int32_t or int64_t? It probably doesn't matter for the things you are counting.…

> 2x as many numbers

Minor correction, 2^32x as many numbers. Though I agree with your point.

Edit: added x to the number for consistency and clarity.

Re: My personal C coding style as of late 2023

#360

Post by terracottalite »

self_awareness wrote: post #239
WalterBright wrote: post #163

Earlier quoted context omitted.

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…

Isn't "int" 64-bit on some (rare) architectures?

My computer being one of those (rare?) architectures. Though I think it is not entirely dependent on the processor and the OS choice also affects this.
Post reply on HN