char (*(*x[3])())[5]
C gets a lot of blame for pointer gibberish like this but quite honestly you can write gibberish in any language. I don't see any fundamental or technical reason you couldn't write clean, readable C.
And the reason it continues to be used is that it is a concise idiom that is useful.
People should not be offended if others critique their work in good faith.
Nobody's fragile ego is worth censoring discussion seeking truth.
Code smell is something that implies deeper issues but isn't usually a serious issue by itself.
I am sorry if you've been assaulted by bad code reviews, but a 'code smell' is a useful idea and term.
typedef char (*fn())[5];
fn x [3];I mean, "a pointer to an array of X" is simply "a pointer to X" and using hungarian notation, you can encode the knowledge "this pointer can be incremented" into its name.
and typedef'ing *function declarations? who has families of functions with the same type signatures that they want to point to?
Granted, the function pointer syntax is forever confusing (to me anyway). The rest is easily tackled by naming things.
Even for function pointers, it’s just one lookup and then you can copy-paste the typedef for any other function pointer types in the project.
typedef int read_block_fn(void *context, u8 *buf, unsigned int block, size_t len);
(NOT the author. It simply helped me.)
What if you're given somebody else's code and you need to understand it to put a typedef there
So you basically take your ugly type, put it in a #define and then create a static assertion that matches the type against said ugly type.
Now the compiler will throw a shit fit if the types don't match. Have fun breaking the type up into smaller pieces until you have something legible.
(Yes, this is a joke)
Next I want one to explain some of Rust’s more cryptic pointer gibberish. Usually I just hit “use suggested fix X” until the compiler’s happy.
I don't think it is gibberish. It's code and in order to read that code you need to understand the language, and to understand language you need learning and experience.
Maybe it can be useful for learning, but if you have to use such tool, I suspect you won't understand it anyway - so in a way it is more a gibberish-to-gibberish translator.
How can such a smart person not not understand how all things that are possible are not all equally good?
The fact that both the compiler and you can parse that doesn't make it a good way to document or convey meaning or intent.
C is chock full of inconsistencies and ambiguities that are only disambiguated by essentially being a human compiler and maintaining the same parsing state-machine manually in your head to know what any given "(" actually means or does. As a self-proclaimed fluent C linguist, you know this better than most.
All coding involves that of course but all implimentations are not equally unhelpful.
The cpu and some people can read the binary itself. They just need to know the cpu's opcodes, documented right in the datasheet that anyone can read.
Then again people complain that they are too verbose, and they rather write in hieroglyph friendly languages.
char (*(*x())[5])();
var x: pointer to func() pointer to array[5] of pointer to func() char;
var x: ^func() ^[5] ^func() char;
Any language with type after name :
// c
char (*(*x[3])())[5];
// golang
var x [3]func() *[5]bytecdecl is always correct with regards to this stuff.
I don't know why you'd choose the former.
Output for the example I got on opening the website:
char (*(*x())[5])()
ChatGPT: x is a function that, when called, gives us access to 5 functions that each return a character. (TL;DR, it gave a full explanation too)
Like mentioned before the error rate of LLMs is probably much higher on complex expressions.
typedef uint64_t qbb_t __attribute__((vector_size(sizeof(uint64_t) * 4)))
Syntax error
OK, its an extension, meh.