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

291–300 of 466 posts

Re: My personal C coding style as of late 2023

#291

Post by uxp8u61q »

habibur wrote: post #276
uxp8u61q wrote: post #271

Honest question: why C? I've been writing C++ firmware for SoCs, supposedly an area where C is supposed to be king, and C++ was just as good, except it came with all the batteries included. So, why C?

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.

> I prefer functions over classes.

Then use functions?

> no mangling of exported names, the binary is re-usable as API.

Not once in my life have I seen someone use a binary as an API.

> in the long term, the C source code is more re-usable in other projects than C++ ones.

I don't even know what you mean by that.

Re: My personal C coding style as of late 2023

#292

Post by Nursie »

cesarb wrote: post #264
Nursie wrote: post #186

Earlier quoted context omitted.

> These types should be defined in the right header stdint.h It's always been amazing to me how many different projects I've worked on (not that I've been in professional C for about 7 years now)) that include their own painstaking recreation of this file. Reusing them and effectively translating them just to your own name is just annoying to the reader IMHO. I am reminded of a C++ project I worked on, where I questi…

> It's always been amazing to me how many different projects I've worked on (not that I've been in professional C for about 7 years now)) that include their own painstaking recreation of this file. How many of them started before stdint.h existed? AFAIK, it's a somewhat recent addition to the C language, and IIRC, for a long time even after it became part of the C standard, some popular C compilers still didn't have…

As recently as eight years ago, on projects started within the previous handful of years. It’s more to do with a lot of C programmers being stuck in a sort of stasis IMHO. (I’m sure I was too in many ways).

And yes, Microsoft were the outlier and absolutely dragged their heels on stdint, but you could always grab a compliant implementation from one of the FOSS projects that produced one.

Re: My personal C coding style as of late 2023

#293

Post by rtz121 »

habibur wrote: post #276
uxp8u61q wrote: post #271

Honest question: why C? I've been writing C++ firmware for SoCs, supposedly an area where C is supposed to be king, and C++ was just as good, except it came with all the batteries included. So, why C?

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.

> - I prefer functions over classes.

I also prefer apples over brooms.

Re: My personal C coding style as of late 2023

#294

Post by tmtvl »

lionkor wrote: post #199

Isn't defining byte = char a bit wrong? char may be signed or unsigned, and may be more or less than 1 byte, right? So why that?

> char may be signed or unsigned,

Correct, the standard does not specify whether char is signed or unsigned, so it's implementation-specific.

> and may be more or less than 1 byte, right?

Wrong, char is specified as a single byte character, so the following will always be true:

  sizeof(char) == 1;

Re: My personal C coding style as of late 2023

#295

Post by uxp8u61q »

circuit10 wrote: post #184
oaiey wrote: post #142

Earlier quoted context omitted.

Yeah but not for basic types. Also, most code mingles sooner or later with other code. Than this is just ugly.

It’s better than dealing with needlessly long type names like uint32_t though

Long type name?? uint32_t is literally 8 characters long. There's not much to cut here.

Re: My personal C coding style as of late 2023

#296

Post by uxp8u61q »

cesarb wrote: post #264
Nursie wrote: post #186

Earlier quoted context omitted.

> These types should be defined in the right header stdint.h It's always been amazing to me how many different projects I've worked on (not that I've been in professional C for about 7 years now)) that include their own painstaking recreation of this file. Reusing them and effectively translating them just to your own name is just annoying to the reader IMHO. I am reminded of a C++ project I worked on, where I questi…

> It's always been amazing to me how many different projects I've worked on (not that I've been in professional C for about 7 years now)) that include their own painstaking recreation of this file. How many of them started before stdint.h existed? AFAIK, it's a somewhat recent addition to the C language, and IIRC, for a long time even after it became part of the C standard, some popular C compilers still didn't have…

inttypes.h was added to C99. A quarter of a century ago.

Re: My personal C coding style as of late 2023

#297

Post by barbs »

avgcorrection wrote: post #227
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…

Thanks for bringing this up. There is no reason for modern languages that have proper constants (not preprocessor macros which happen to sometimes be used for them) to use this tedious style. Constants are so innocent and useful. Why indirectly discourage their use by making their usage an eye-bleed?

What alternative would you suggest?

Re: My personal C coding style as of late 2023

#298

Post by rocqua »

adrianN wrote: post #290
Lockal wrote: post #260

Earlier quoted context omitted.

Just a note: defining own integer types has sense for resource-limited platforms. Most common type I see is something like "dim_t", which is 32-bit or 64-bit depending on use-case. 32-bit integers are often used even on 64-bit platforms in pointer compression schemes (for example, allocate your own heap and only store 32-bit offsets). This not only gives 2x improvement on memory usage for <4GB workloads, but it also…

How does it improve locality?

More 'pointers' (32 bit offset ints) fit on a single cache line. Or, put differently, a list off offsets is half as long amd hence everything om the list is twice as close to everything else on the list.

Re: My personal C coding style as of late 2023

#299

Post by galangalalgol »

colejohnson66 wrote: post #286
self_awareness wrote: post #239

Earlier quoted context omitted.

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

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.

Re: My personal C coding style as of late 2023

#300

Post by seanw444 »

uxp8u61q wrote: post #295
circuit10 wrote: post #184

Earlier quoted context omitted.

It’s better than dealing with needlessly long type names like uint32_t though

Long type name?? uint32_t is literally 8 characters long. There's not much to cut here.

How about... u32?
Post reply on HN