Rendered at 14:21:56 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
wren6991 24 hours ago [-]
> (everything here also applies to c2y's newly introduced _Countof)
Stop the press, they're adding what? So I don't have to keep adding #define count_of(arr) (sizeof(arr) / sizeof(*arr)) to every codebase and living with its failure modes?
I'm really loving C's character arc at the moment, where they keep going back to fix old problems instead of piling everything and the kitchen sink into the language.
zbentley 21 hours ago [-]
> I'm really loving C's character arc at the moment, where they keep going back to fix old problems
Valid, but it does seem a bit Stockholm Syndrome to have this much rejoicing that your language added a builtin for getting the length of an array in 2026.
pjmlp 7 hours ago [-]
If only they actually fixed arrays and strings properly.
C23 and C2y have plenty of kitchen sink features.
HexDecOctBin 23 hours ago [-]
Yeah, despite puritanical hand-wringing over C23, I do like both the discipline and the selectivity with WG14 has shows (and I say this as a card-carrying C++ hater).
I do wish they will start looking into proper arrays since there is already a syntax for this can can be augmented semantically:
int func (int arg[static 5])
uecker 18 hours ago [-]
Can you explain what you mean exactly regarding this augmenting this syntax?
wren6991 17 hours ago [-]
I guess they are saying sizeof(...) should return the annotated static size rather than sizeof(int*) in this case
glouwbug 22 hours ago [-]
It's a unary operator, kind of like ~ or !, which can apply to parenthesis (), until it meets a type, then the parenthesis are mandatory:
int x;
sizeof x; // okay
sizeof (x); // okay
sizeof int; // not okay
sizeof (int); // okay
It's a weird double rule to parse, but even worse, the strongest binding precedence typically doesn't like an alpha identifier at that point in the recursive descent, so you get weird rules like:
read_prefix():
is peak() '!': ...
is peak() '~": ...
is alpha(peak())
maybe alpha is sizeof?
wait, it wasn't sizeof? it was an identifier? long rewind
is peak() '+': ...
Something like @ would've been a good pick for sizeof.
\ramble on
(actually, better yet, it should've been used instead of & for taking the address). Imagine:
int x;
int* p = @x;
\ramble off
atiedebee 7 hours ago [-]
Ive actually toyed with the idea of having @ as a pointer dereference. It seems to make sense: you want to know what is at the address stored in p.
19 hours ago [-]
high_na_euv 23 hours ago [-]
I feel like what you struggle with is expression parsing, not sizeof itself?
inigyou 23 hours ago [-]
Wait, they added a new operator and didn't fix that parsing stupidity by always requiring parentheses?
adrian_b 21 hours ago [-]
I assume that there would be a zillion of legacy C source files that would be broken by such a change.
inigyou 21 hours ago [-]
There are no legacy C source files using _Countof.
uecker 20 hours ago [-]
That was discussed, but consistency with sizeof was considered more important. And if you figured out how to parse sizeof, parsing countof is not an additional burden.
Stop the press, they're adding what? So I don't have to keep adding #define count_of(arr) (sizeof(arr) / sizeof(*arr)) to every codebase and living with its failure modes?
I'm really loving C's character arc at the moment, where they keep going back to fix old problems instead of piling everything and the kitchen sink into the language.
Valid, but it does seem a bit Stockholm Syndrome to have this much rejoicing that your language added a builtin for getting the length of an array in 2026.
C23 and C2y have plenty of kitchen sink features.
I do wish they will start looking into proper arrays since there is already a syntax for this can can be augmented semantically:
\ramble on
(actually, better yet, it should've been used instead of & for taking the address). Imagine:
\ramble off