Live data from Hacker News

Show HN: Cdecl-dump - represent C declarations visually

github.com

1–10 of 15 posts

Show HN: Cdecl-dump - represent C declarations visually

#1
A small tool that parses C declarations and outputs a simple visual representation at each stage, as it encounters arrays, pointers or functions.

The program uses a table-driven lexer and a hand-written, shift-reduce parser. No external dependencies apart from the standard library.

Show HN: Cdecl-dump - represent C declarations visually
github.com

Re: Show HN: Cdecl-dump - represent C declarations visually

#3
Since this is about C declarations: for anyone who (like me) had the misfortune of learning the so-called "spiral rule" in college rather than being taught how declarations in C work, below are some links that explain the "declaration follows use" idea that (AFAIK) is the true philosophy behind C declaration syntax (and significantly easier to remember/read/write).

TL;DR: you declare a variable in C _in exactly the same way you would use it:_ if you know how to use a variable, then you know how to read and write a declaration for it.

https://eigenstate.org/notes/c-decl https://news.ycombinator.com/item?id=12775966

Re: Show HN: Cdecl-dump - represent C declarations visually

#4

I don’t understand what the visualisation screenshot in the README is trying to communicate to me.

It starts from the identifier. At every stage, it outputs a sub-expression which is the “mirrored use” and corresponds to the boxed representation below it. When it reaches the top of the expression, it prints the final type of the expression which is the lone specifier-qualifier list.

As per the screenshot, “arr” is an array of 4 elements. Consequently, “arr[0]” is an array of 8 elements. Then, “arr[0][0]” is a pointer. And so on, until we arrive at the specifier-qualifier list.

Re: Show HN: Cdecl-dump - represent C declarations visually

#5
post #3

Since this is about C declarations: for anyone who (like me) had the misfortune of learning the so-called "spiral rule" in college rather than being taught how declarations in C work, below are some links that explain the "declaration follows use" idea that (AFAIK) is the true philosophy behind C declaration syntax (and significantly easier to remember/read/write). TL;DR: you declare a variable in C _in exactly the s…

That is correct.

  int x, *p, arr[5], fn(), (*pfn)();
Using x, or dereferencing p, or subscripting the array arr, or declaring a function that can be called with fn, or dereferencing the function pointer pfn then calling it, all these things would produce an int.

It's the intended way to read/write declarations/expressions. As a consequence, asterisks ends up placed near the identifiers. The confused ones will think it's a stylistic choice and won't understand any of this.

Re: Show HN: Cdecl-dump - represent C declarations visually

#6
post #5
post #3

Since this is about C declarations: for anyone who (like me) had the misfortune of learning the so-called "spiral rule" in college rather than being taught how declarations in C work, below are some links that explain the "declaration follows use" idea that (AFAIK) is the true philosophy behind C declaration syntax (and significantly easier to remember/read/write). TL;DR: you declare a variable in C _in exactly the s…

That is correct. int x, *p, arr[5], fn(), (*pfn)(); Using x, or dereferencing p, or subscripting the array arr, or declaring a function that can be called with fn, or dereferencing the function pointer pfn then calling it, all these things would produce an int. It's the intended way to read/write declarations/expressions. As a consequence, asterisks ends up placed near the identifiers. The confused ones will think it…

Of course, the correct way to use a function pointer is to call it.

Re: Show HN: Cdecl-dump - represent C declarations visually

#7
post #5

Earlier quoted context omitted.

That is correct. int x, *p, arr[5], fn(), (*pfn)(); Using x, or dereferencing p, or subscripting the array arr, or declaring a function that can be called with fn, or dereferencing the function pointer pfn then calling it, all these things would produce an int. It's the intended way to read/write declarations/expressions. As a consequence, asterisks ends up placed near the identifiers. The confused ones will think it…

Of course, the correct way to use a function pointer is to call it.

Yes, the () operator dereference function pointers automatically for you for convenience. There's also the surprise that you can infinitely dereference function pointers as they just yield you more function pointers.

Re: Show HN: Cdecl-dump - represent C declarations visually

#8

I don’t understand what the visualisation screenshot in the README is trying to communicate to me.

It starts from the identifier. At every stage, it outputs a sub-expression which is the “mirrored use” and corresponds to the boxed representation below it. When it reaches the top of the expression, it prints the final type of the expression which is the lone specifier-qualifier list. As per the screenshot, “arr” is an array of 4 elements. Consequently, “arr[0]” is an array of 8 elements. Then, “arr[0][0]” is a poin…

[deleted]

Re: Show HN: Cdecl-dump - represent C declarations visually

#9
post #5
post #3

Since this is about C declarations: for anyone who (like me) had the misfortune of learning the so-called "spiral rule" in college rather than being taught how declarations in C work, below are some links that explain the "declaration follows use" idea that (AFAIK) is the true philosophy behind C declaration syntax (and significantly easier to remember/read/write). TL;DR: you declare a variable in C _in exactly the s…

That is correct. int x, *p, arr[5], fn(), (*pfn)(); Using x, or dereferencing p, or subscripting the array arr, or declaring a function that can be called with fn, or dereferencing the function pointer pfn then calling it, all these things would produce an int. It's the intended way to read/write declarations/expressions. As a consequence, asterisks ends up placed near the identifiers. The confused ones will think it…

> It's the intended way to read/write declarations/expressions. As a consequence, asterisks ends up placed near the identifiers.

You know you don't always have to use things as they were intended?

> The confused ones will think it's a stylistic choice and won't understand any of this.

Well, I've written it both ways, and the compiler never seems to mind. :)

Maybe I should start putting space on both sides of the asterisk; seems like it would be a good way to annoy even more people.

Re: Show HN: Cdecl-dump - represent C declarations visually

#10
post #5
post #3

Since this is about C declarations: for anyone who (like me) had the misfortune of learning the so-called "spiral rule" in college rather than being taught how declarations in C work, below are some links that explain the "declaration follows use" idea that (AFAIK) is the true philosophy behind C declaration syntax (and significantly easier to remember/read/write). TL;DR: you declare a variable in C _in exactly the s…

That is correct. int x, *p, arr[5], fn(), (*pfn)(); Using x, or dereferencing p, or subscripting the array arr, or declaring a function that can be called with fn, or dereferencing the function pointer pfn then calling it, all these things would produce an int. It's the intended way to read/write declarations/expressions. As a consequence, asterisks ends up placed near the identifiers. The confused ones will think it…

Blame Stroustrup.

https://www.stroustrup.com/bs_faq2.html#whitespace

Post reply on HN