I'm more of the mindset that writing something like this is probably a code smell to begin with. Is there any reason I'm not thinking of right now, that this couldn't be typedef'd and refactored into something far more readable?
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.
Why do people continue to use this term "code smell", instead of "hard to read code" or something similar, more equivalent??? First seem almost offensive to an author.
Rust isn't so bad, is it? The example of `char ((x[3])())[5]` would translate to `[fn() -> [fn() -> u8; 5]; 3]`. It's inherently an ugly type, but I think it's easier to read than the C version.
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.
I disagree. The conventions for declaring arrays, pointers, and function pointers are all idiosyncratic. In C, the type is always to the left of the variable being declared. Except for arrays, which have part of the declaration to the right. And except for pointers, which need to be affixed to every item if there are multiple declarations. And except for function pointers where you need to wrap the variable name like (*name). Individually I can wrap my head around these exceptions, but putting all of them together, it's just hard to read.
It takes a pretty smart person to do that. Which is pretty confusing.
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.
ashleyn|1 year ago
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.
unknown|1 year ago
[deleted]
danielEM|1 year ago
theanonymousone|1 year ago
jacoblambda|1 year ago
pavlov|1 year ago
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.
khrbtxyz|1 year ago
dapperdrake|1 year ago
(NOT the author. It simply helped me.)
sebstefan|1 year ago
What if you're given somebody else's code and you need to understand it to put a typedef there
elcritch|1 year ago
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.
Thiez|1 year ago
makach|1 year ago
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.
tuveson|1 year ago
Brian_K_White|1 year ago
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.
card_zero|1 year ago
chongli|1 year ago
[1] https://docs.racket-lang.org/htdp-langs/beginner.html
pjmlp|1 year ago
Then again people complain that they are too verbose, and they rather write in hieroglyph friendly languages.
unrealhoang|1 year ago
Any language with type after name :
dogleash|1 year ago
sitzkrieg|1 year ago
marginalia_nu|1 year ago
pwilson7|1 year ago
vzaliva|1 year ago
ngcc_hk|1 year ago
djmips|1 year ago
veltas|1 year ago
marginalia_nu|1 year ago
cdecl is always correct with regards to this stuff.
I don't know why you'd choose the former.
andix|1 year ago
Output for the example I got on opening the website:
cdecl.org: declare x as function returning pointer to array 5 of pointer to function returning charChatGPT: 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.
dangsux|1 year ago
[deleted]
lynx23|1 year ago
typedef uint64_t qbb_t __attribute__((vector_size(sizeof(uint64_t) * 4)))
Syntax error
OK, its an extension, meh.
veltas|1 year ago
kmoser|1 year ago