Earlier quoted context omitted.
Long type name?? uint32_t is literally 8 characters long. There's not much to cut here.
How about... u32?
Unsigned 32 bit IEEE 754 floating point, right?
My personal C coding style as of late 2023
451–460 of 466 posts
Re: My personal C coding style as of late 2023
#452Earlier quoted context omitted.
It's definitely part of the linux kernel coding style: https://www.kernel.org/doc/html/v4.10/process/coding-style.h...
That's all fine, but you cannot have nicely behaved stack allocated structs and use the data hiding method outlined in that blog post, which I think is a pretty big caveat
Yes, allowing clients to control allocation of a struct is a crucial feature of any C API, especially if it's going to be used on embedded targets where heap is unavailable or restricted.
The pattern I like to use for this is to expose class definitions, and declare each field with an underscore suffix to indicate it's private.
typedef struct Foo {
int x_; // implementation detail. don't touch.
} Foo;
// foo.h
#define FOO_SIZE_ 4
#define FOO_ALIGN_ 4
typedef struct Foo {
_Alignas(FOO_ALIGN_) char impl_[FOO_SIZE_];
} Foo;
// foo.c
#include "foo.h"
typedef struct FooImpl {
int x;
} FooImpl;
_Static_assert(FOO_SIZE_ == sizeof(FooImpl), "");
_Static_assert(FOO_ALIGN_ == _Alignof(FooImpl), "");
void Foo_bar(Foo const* self_opaque) {
FooImpl const* self = (FooImpl)self_opaque;
...
}
Re: My personal C coding style as of late 2023
#453Earlier quoted context omitted.
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?
Just use the same style as for variables. What's the point of the distinction? Maybe you'll want to change a constant into a variable later.
Re: My personal C coding style as of late 2023
#454Earlier quoted context omitted.
> What I mean by "bend the rules of arithmetic" is that if we decrement from zero, we suddenly get a large value. Yes completely consistent with rules of modular arithmetic. A programmer ought to be able to extend math horizons beyond preschool. Which is ironic because I can explain this concept to my 6 year old on a clock face and it’s easy for them to grasp. > Unsigned tricks with circular buffer indices will not d…
> Yes completely consistent with rules of modular arithmetic. In modular arithmetic, there is no such thing as <. (To put it precisely, ℤ_𝑛 is not an ordered ring.) Or are you teaching your 6-year old that 9:00 today is later than 7:00 tomorrow?
Unsigned arithmetic is useful for wrapping clocks, like interrupt tick counters and whatnot. There is always some current value, "now". There is a range of it defined as the future. Everything outside of that range is considered past. Timers are never set farther into the future beyond the range, and are expired in a timely way so that unexpired timers never recede sufficiently far into the past that they appear to flip to the future. One way of doing it is to just cut the range in half: take the difference between two times t1 - t0 and cast it to the same-sized signed type. If the difference is positive, then t1 is in the future relative to t0. If negative, t1 is in the past relative to t0.
This is one of those niche uses of unsigned.
You probably want to hide it behind an API, where the domain is opaque and abstract and you have function such as a time_before(t1, t0) predicate.
Re: My personal C coding style as of late 2023
#455Earlier quoted context omitted.
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.
What machine are you using?
Umm, sorry I remembered that wrong. Turns out int isn't 64 bits on my machine. I should double check before posting next time. (I mistaked long with int, and long isn't 64 bits on some systems). I can't delete it now.
Re: My personal C coding style as of late 2023
#456Earlier quoted context omitted.
> What I mean by "bend the rules of arithmetic" is that if we decrement from zero, we suddenly get a large value. Yes completely consistent with rules of modular arithmetic. A programmer ought to be able to extend math horizons beyond preschool. Which is ironic because I can explain this concept to my 6 year old on a clock face and it’s easy for them to grasp. > Unsigned tricks with circular buffer indices will not d…
> Yes completely consistent with rules of modular arithmetic. In modular arithmetic, there is no such thing as <. (To put it precisely, ℤ_𝑛 is not an ordered ring.) Or are you teaching your 6-year old that 9:00 today is later than 7:00 tomorrow?
[deleted]
Re: My personal C coding style as of late 2023
#457Re: My personal C coding style as of late 2023
#458I get that everyone has their own coding style, but ditching established conventions in C for personal aesthetic seems a bit much. Like, using u8 or i32 instead of the standard uint8_t or int32_t might save a few keystrokes, but it could confuse anyone else looking at the code. And the custom string type over null-terminated strings? C's built around those, and deviating from that just feels like making life harder f…
> Like, using u8 or i32 instead of the standard uint8_t or int32_t might save a few keystrokes, but it could confuse anyone else looking at the code.
This seems a theoretical possibility _at best_, and a fairly strawman-y one at that. I doubt any competent C programmer would get "confused". Irritated at a different style, maybe.
Too, everything is hard to read before you learn to read it. -- Rich Hickey
Re: My personal C coding style as of late 2023
#459Earlier quoted context omitted.
Of course plenty of people are confused, the overhead of "short/long" just makes no sense, but yet another bad design from the past carefully preserved
Haven't run into a confused one yet, and D has been around 20 years.
That's just an indication of who you run into if you've missed people noticing/getting confused by this pretty obvious flaw
Re: My personal C coding style as of late 2023
#460Earlier quoted context omitted.
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.
You do none. You program FOR the binary world, but in a complex 3D reality