I can read that. 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.
C Gibberish to English
31–40 of 54 posts
Re: C Gibberish to English
#32Earlier quoted context omitted.
Because if you don't do things exactly the way cdecl wants you get a Syntax Error
Wouldn't any explanation given, apart from syntax error, be wrong in the case you provide it with an invalid syntax?
Re: C Gibberish to English
#33char (*(*x[3])())[5] 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 coul…
Re: C Gibberish to English
#34char (*(*x[3])())[5] 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 coul…
typedef char (*fn())[5];
and then you have the original as fn x [3];Re: C Gibberish to English
#35Use typedef? 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.
>Use typedef? 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.
Re: C Gibberish to English
#36Re: C Gibberish to English
#37char (*(*x[3])())[5] 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 coul…
the function signature certainly should be type def-ed. i.e. typedef char (*fn())[5]; and then you have the original as 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?
Re: C Gibberish to English
#38I can read that. 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.
Re: C Gibberish to English
#39Earlier quoted context omitted.
the function signature certainly should be type def-ed. i.e. typedef char (*fn())[5]; and then you have the original as fn x [3];
I don't keep up with the latest C shenanigans, cuz I like C the way it was, but have they change something where "pointer to an array[5]" is a meaningful distinction to draw? 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 wit…
This has been a meaningful distinction since at least C99.
> "a pointer to an array of X" is simply "a pointer to X"
They aren't actually the same. The former can be decayed into the latter but they aren't actually equivalent and you'll get type mismatches if you try to treat them as the same thing.
> who has families of functions with the same type signatures that they want to point to
An example is callbacks or handlers for responding to interrupt requests. A lot of hardware interface code relies on typedef-ed function decls because very often you are passing user side functions through your interface so that you can stash those function pointers somewhere and invoke them when some event occurs.
Re: C Gibberish to English
#40char (*(*x[3])())[5] 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 coul…