Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Gibberish to English

cdecl.org

Post reply on HN
Print view View original

41–50 of 54 posts

Re: C Gibberish to English

#41

Post by [deleted] »

CuriousCosmic wrote: post #39
fsckboy wrote: post #37

Earlier quoted context omitted.

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…

> but have they change something where "pointer to an array[5]" is a meaningful distinction to draw 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…

[deleted]

Re: C Gibberish to English

#42

Post by kelnos »

fsckboy wrote: post #37
CuriousCosmic wrote: post #34

Earlier 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…

> "a pointer to an array of X" is simply "a pointer to X"

I don't believe these two are the same. An "array of X" indeed decays to a "pointer to X". But a "pointer to an array of X" is something else. E.g.

    int foo[3];  // array of int
    int *foo;    // pointer to int
    int *foo[3]; // pointer to array of int
Perhaps the first two are what you mean, though, and this is just a terminology issue.

Re: C Gibberish to English

#43

Post by fsckboy »

kelnos wrote: post #42
fsckboy wrote: post #37

Earlier quoted context omitted.

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…

> "a pointer to an array of X" is simply "a pointer to X" I don't believe these two are the same. An "array of X" indeed decays to a "pointer to X". But a "pointer to an array of X" is something else. E.g. int foo[3]; // array of int int *foo; // pointer to int int *foo[3]; // pointer to array of int Perhaps the first two are what you mean, though, and this is just a terminology issue.

  int *foo[3]; // pointer to array of int
that's an array of 3 pointers to ints. if you pass foo as an argument you get a pointer to a pointer to an int (with knowledge if you can hang onto it that there are more pointers to ints lined up in memory)

Re: C Gibberish to English

#45

Post by danielEM »

ashleyn wrote: post #25

char (*(*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…

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.

Re: C Gibberish to English

#46

Post by dragonwriter »

danielEM wrote: post #45
ashleyn wrote: post #25

char (*(*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…

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.

“Code smell” does not mean “hard to read code”, it means “an unreliable but still useful indication that there may be something wrong in the design of the code connected to the piece described as having the ‘smell’”.

And the reason it continues to be used is that it is a concise idiom that is useful.

Re: C Gibberish to English

#47

Post by danielEM »

dragonwriter wrote: post #46
danielEM wrote: post #45

Earlier quoted context omitted.

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.

“Code smell” does not mean “hard to read code”, it means “an unreliable but still useful indication that there may be something wrong in the design of the code connected to the piece described as having the ‘smell’”. And the reason it continues to be used is that it is a concise idiom that is useful.

"an unreliable but still useful indication that there may be something wrong in the design of the code"

Well, but you just proved the point - it can be described in non offensive manner. And more over, judging something based on gut feeling ("indication") may be actually even worse, as you may offend someone who did actually a good job.

Sorry if "nit picking", recently was reading a lot about burn outs in the industry, and this is a thing that did catch my attention...

Re: C Gibberish to English

#48

Post by tpoacher »

danielEM wrote: post #47
dragonwriter wrote: post #46

Earlier quoted context omitted.

“Code smell” does not mean “hard to read code”, it means “an unreliable but still useful indication that there may be something wrong in the design of the code connected to the piece described as having the ‘smell’”. And the reason it continues to be used is that it is a concise idiom that is useful.

"an unreliable but still useful indication that there may be something wrong in the design of the code" Well, but you just proved the point - it can be described in non offensive manner. And more over, judging something based on gut feeling ("indication") may be actually even worse, as you may offend someone who did actually a good job. Sorry if "nit picking", recently was reading a lot about burn outs in the industr…

I don't think it's meant to be offensive.

It's "smell" in the same sense as "something smells fishy here", or "I smell trouble", with smell serving the analogy of being the least specific of your senses, alluding to having a non-specific feeling rather than hard evidence about something. In theory there's no implication of a "repulsive / offensive smell" or "ew this code smells" in the phrase, like you seem to perceive it.

Granted, these things are subjective, but it's similar to complaining about the term black humour being racist, when black in this context is not meant to have any racial context.

Re: C Gibberish to English

#49

Post by tpoacher »

fsckboy wrote: post #43
kelnos wrote: post #42

Earlier quoted context omitted.

> "a pointer to an array of X" is simply "a pointer to X" I don't believe these two are the same. An "array of X" indeed decays to a "pointer to X". But a "pointer to an array of X" is something else. E.g. int foo[3]; // array of int int *foo; // pointer to int int *foo[3]; // pointer to array of int Perhaps the first two are what you mean, though, and this is just a terminology issue.

int *foo[3]; // pointer to array of int that's an array of 3 pointers to ints. if you pass foo as an argument you get a pointer to a pointer to an int (with knowledge if you can hang onto it that there are more pointers to ints lined up in memory)

Yes, but this is different:

  int (* foo) [3]
This is a pointer to an array of 3 ints.

And you could pass this to an appropriate function as an argument, to pass the whole array, not just a decayed pointer.

And more generally, I'd group things as unambiguously as possible even in your example:

    int * (foo [3])
to make the intent clearer

Re: C Gibberish to English

#50

Post by kmoser »

lynx23 wrote: post #7

Why is it that the first thing I try tends to uncover shortcomings? typedef uint64_t qbb_t __attribute__((vector_size(sizeof(uint64_t) * 4))) Syntax error OK, its an extension, meh.

This failed because it doesn't do math: int *x[10/2]
Post reply on HN