10 ms·

Cdecl: C Gibberish ↔ English

95 points by mkl95 5y ago

IYasha 5y ago
> demo 1 > declare bar as volatile pointer to array 64 of const int Maybe "declare bar as volatile pointer to array of 64 const int" will sound more smooth? :)
andi999 5y ago
Everytime I read the chapter in K&R, I first get a headache, then I think I understand it, then I think I dont understand it, but it is something very easy (just follow the circle rule). Then next year the cycle repeats.
- MauranKilom 5y ago
  Except the circle rule doesn't really help unless you know when to skip stuff because you're not done on the other side. The right-left rule instead is precise and correct. See https://news.ycombinator.com/item?id=5080081 https://news.ycombinator.com/item?id=5080081 and https://web.archive.org/web/20190714064656/http://cseweb.ucsd.edu/~ricko/rt_lt.rule.html https://web.archive.org/web/20190714064656/http://cseweb.ucs...
  - spicybright 5y ago
    I'm actually surprised I had to read this far down the comments to see a reference to the right-left rule. Is that not common knowledge anymore for C programmers?
SaulJLH 5y ago
Site is very sparse, I "think" I know what this is for, but I'm probably wrong, can anyone explain?
- EMM_386 5y ago
  Type in some syntax in the C programming language, it will translate it into English to help you get a better mental picture of what is going on.
  - SaulJLH 5y ago
    That's literally it? Thought might be more to it, hmm still interesting, thanks!
    - theophrastus 5y ago
      Well it goes the other way too. English to arcane C declaration. And that's what many of us have used it for decades (and decades...). Try: declare xyzzyx as pointer to pointer to array 153 of const double
- krossitalk 5y ago
  I think of it as a programmers aide much like regex101.com or crontab.guru
  - Tempest1981 5y ago
    Also: - https://fuckingfunctionpointers.com/ https://fuckingfunctionpointers.com/ - http://fuckingblocksyntax.com/ http://fuckingblocksyntax.com/
jonpalmisc 5y ago
Surprised to see this is the second result when googling “cdecl” despite its naming collision with the calling convention.
- buescher 5y ago
  The unix utility probably predates the Microsoft C compiler.
xscott 5y ago
The biggest problem with C's pointer syntax is that it's prefix. If pointers were suffix, perhaps using a character that isn't doing primary duty as the multiplication operator, there wouldn't be any need for a Gibberish to English translator. Maybe think of @ as "address": int i; // variable which is integer int p@; // pointer that returns integer int f(); // function returns integer int f@(); // pointer to function int f()@; // funtion that returns pointer int a[10]; // array of ten integers int a[10]@; // array of ten pointers int a@[10]; // pointer to and array int a[10]()@; // array of ten functions that return a pointer Of course C is stuck with accidents/decisions made 50 years ago. But a language like Go turns all the declaration syntax on its head and still doesn't solve the problem. Rob Pike's blog post says as much (scroll to the bottom section on pointers): https://go.dev/blog/declaration-syntax https://go.dev/blog/declaration-syntax He suggests Pascal's caret syntax (^), which wouldn't work if it was also used as the binary xor operator.
- thwd 5y ago
  Go solves 99% of the problem quite nicely. You don't often deref pointers in Go, because of auto-addressing. E.g. there's no arrow operator as in C, the dot derefs when necessary. I would say `v := (p.)` could've been the deref operator, but what do I know.
  - masklinn 5y ago
    That you don't deref pointers in Go is not what fixes this issue. What fixes this issue is that, like most other languages which are not C, Go understands that "is a pointer" is a property of the type, not the name / value. So even if it used C-style declaration, Go would say *int p or, using a more verbose syntax Pointer[int] p
    - kevin_thibedeau 5y ago
      Even C isn't consistent about this: int * a, b; // "Property" of the variable typedef int * pint; pint x, y; // Property of the type This has created so much bad legacy code where pointer typedefs are created for no good reason.
buescher 5y ago
Yeah, thanks to C pointer syntax, there's a big faction of programmers that think that understanding indirect addressing is a major intellectual accomplishment. I don't have anything better to offer though - C pointers make a whole lot possible in a very terse way.
- cryptoshit 5y ago
  Easiest way to understand pointers is to learn it in assembler first, which is closer to what's actually going on. Then when learning the C syntax, it all fits into place neatly, rather than being mysterious asterisks and so on.
  - mwattsun 5y ago
    I can't imagine being a programmer without starting out by becoming proficient in assembler. It takes a lot of mystery out of programming languages because you know whatever the syntax is it all ends up as branches, calls, stacks, registers and memory accesses.
    - eternityforest 5y ago
      If you want to do embedded I would kind of agree(But C is low level enough), otherwise... I'm not so sure. Low level languages teach a lot of habits I don't like, and they don't teach as much about working in a modern high level environment on complex software. Everyone should probably be vaguely competent with C, but I wouldn't call it a top priority. If you're thinking about the underlying machine stuff when coding in Python, you're kind of just accepting leaky abstractions. If you're in the habit of first principles thinking, leaks seem normal. C doesn't really seem to layer all that well. Whenever I code in C, I usually have to dig down to the SDK API level, and I wind up reading 10 other files to make a change in 1. High level languages make it clear when something isn't DRY, or an abstraction leaks, or something isn't usable without modification. It's unusual, you notice right away, and you want to fix it because it obviously doesn't fit. Low level languages make everything feel totally patched together. Encapsulation just isn't a big thing in most of it. It's almost like looking at an old point to point wired TV set compared to a rack of servers. You might be able to write some amazing ASM code that feels as modern as some top notch Kotlin... but I'd call that an expert, not just a competent person. And worst of all, the compiler can't catch many bugs. It's not like Rust. Or even Python. Low level languages don't teach the art of making sure that the computer has your back, the way Rust might. They normalize just entirely relying on your own skill, to the point where some C devs don't even seem to want the compiler to eliminate large classes of bugs for them. High level languages teach a real appreciation of abstraction and safety, and standardization, that I don't feel like I really learned with C.
flohofwoe 5y ago
When you arrive at the sort of gibberish that you need a tool to make sense of it, it's time to split the declaration into several much simpler typedef building blocks (especially recommended for function types). Also for what it's worth, this isn't 'human readable' either, or is it?: "declare foo as pointer to function (pointer to const void) returning pointer to array 3 of int"
- bool3max 5y ago
  That seems perfectly readable to me, sans the part in the parentheses.
jbandela1 5y ago
If you are using C++, you can make this a lot easier using this template alias template<typename T> using ptr = T*; ptr<const char> str: const ptr<char> pchar; ptr<void(ptr<const char>)> fun_ptr; Basically this simple trick removes most of the confusion, and you can read the types left to right.
- jcelerier 5y ago
  It also makes function pointer types much clearer: using func_ptr = float(int); // Given float some_func(int); // Then func_ptr* a = &some_func; // Also func_ptr* b = [] (int x) { return 0.f; };
teddyh 5y ago
You know, you could just apt install cdecl And then do it on the command line. But hey, let's turn everything into a web service, with monitoring as a bonus feature. (Repost of https://news.ycombinator.com/item?id=11164685 https://news.ycombinator.com/item?id=11164685)
marcodiego 5y ago
It would be good if there was something similar for the other constructs, like statements, loops, calls... That would become a "C" to natural language translator. I wonder how hard it is to turn: for(int i = 0; i < x; i++) into "declare 'i' as int and assign '0' to it; while 'i' is smaller than 'x' do ... and increment 'i'."
derw-lang 5y ago
As part of Derw, I've added an English output generator[0], with the idea that the output could be used to improve error messages or help developers understand unfamiliar syntax, particularly for those more used to Javascript rather than ML. Similar concept to cdecl 0 - https://mobile.twitter.com/derwlang/status/1505709982024671238 https://mobile.twitter.com/derwlang/status/15057099820246712...
emmanueloga_ 5y ago
what's stopping a new version of C from defining a better declaration syntax? (better = easier to read, write and understand)
- RTFM_PLEASE 5y ago
  1) 50 years of backwards compatibility. 2) It is not necessary. C's terse syntax is not hard to understand for anyone who actually uses the language. Most of the comments here are from people who do not.
  - xigoi 5y ago
    You can add new syntax without destroying backward compatibility, as long as it doesn't conflict with existing syntax. C++ took C and added the std::unique_ptr<int> syntax, which is much more readable.
mattiii 5y ago
the c pointer syntax is perfectly fine after realize you its just the operator precedence rules but in reverse. int foo, *bar, baz(), (*zyzzy())(); i do not understand why blowhard rob pike types dislike it. its exactly the kind of elegant you would think they would like

95 points by mkl95 5y ago

> demo 1 > declare bar as volatile pointer to array 64 of const int Maybe "declare bar as volatile pointer to array of 64 const int" will sound more smooth? :)

andi999 5y ago

Everytime I read the chapter in K&R, I first get a headache, then I think I understand it, then I think I dont understand it, but it is something very easy (just follow the circle rule). Then next year the cycle repeats.

MauranKilom 5y ago
Except the circle rule doesn't really help unless you know when to skip stuff because you're not done on the other side. The right-left rule instead is precise and correct. See https://news.ycombinator.com/item?id=5080081 https://news.ycombinator.com/item?id=5080081 and https://web.archive.org/web/20190714064656/http://cseweb.ucsd.edu/~ricko/rt_lt.rule.html https://web.archive.org/web/20190714064656/http://cseweb.ucs...
- spicybright 5y ago
  I'm actually surprised I had to read this far down the comments to see a reference to the right-left rule. Is that not common knowledge anymore for C programmers?

SaulJLH 5y ago

Site is very sparse, I "think" I know what this is for, but I'm probably wrong, can anyone explain?

EMM_386 5y ago
Type in some syntax in the C programming language, it will translate it into English to help you get a better mental picture of what is going on.
- SaulJLH 5y ago
  That's literally it? Thought might be more to it, hmm still interesting, thanks!
  - theophrastus 5y ago
    Well it goes the other way too. English to arcane C declaration. And that's what many of us have used it for decades (and decades...). Try: declare xyzzyx as pointer to pointer to array 153 of const double
krossitalk 5y ago
I think of it as a programmers aide much like regex101.com or crontab.guru
- Tempest1981 5y ago
  Also: - https://fuckingfunctionpointers.com/ https://fuckingfunctionpointers.com/ - http://fuckingblocksyntax.com/ http://fuckingblocksyntax.com/

jonpalmisc 5y ago

Surprised to see this is the second result when googling “cdecl” despite its naming collision with the calling convention.

buescher 5y ago
The unix utility probably predates the Microsoft C compiler.

xscott 5y ago

The biggest problem with C's pointer syntax is that it's prefix. If pointers were suffix, perhaps using a character that isn't doing primary duty as the multiplication operator, there wouldn't be any need for a Gibberish to English translator. Maybe think of @ as "address": int i; // variable which is integer int p@; // pointer that returns integer int f(); // function returns integer int f@(); // pointer to function int f()@; // funtion that returns pointer int a[10]; // array of ten integers int a[10]@; // array of ten pointers int a@[10]; // pointer to and array int a[10]()@; // array of ten functions that return a pointer Of course C is stuck with accidents/decisions made 50 years ago. But a language like Go turns all the declaration syntax on its head and still doesn't solve the problem. Rob Pike's blog post says as much (scroll to the bottom section on pointers): https://go.dev/blog/declaration-syntax https://go.dev/blog/declaration-syntax He suggests Pascal's caret syntax (^), which wouldn't work if it was also used as the binary xor operator.

thwd 5y ago
Go solves 99% of the problem quite nicely. You don't often deref pointers in Go, because of auto-addressing. E.g. there's no arrow operator as in C, the dot derefs when necessary. I would say `v := (p.)` could've been the deref operator, but what do I know.
- masklinn 5y ago
  That you don't deref pointers in Go is not what fixes this issue. What fixes this issue is that, like most other languages which are not C, Go understands that "is a pointer" is a property of the type, not the name / value. So even if it used C-style declaration, Go would say *int p or, using a more verbose syntax Pointer[int] p
  - kevin_thibedeau 5y ago
    Even C isn't consistent about this: int * a, b; // "Property" of the variable typedef int * pint; pint x, y; // Property of the type This has created so much bad legacy code where pointer typedefs are created for no good reason.

buescher 5y ago

Yeah, thanks to C pointer syntax, there's a big faction of programmers that think that understanding indirect addressing is a major intellectual accomplishment. I don't have anything better to offer though - C pointers make a whole lot possible in a very terse way.

cryptoshit 5y ago
Easiest way to understand pointers is to learn it in assembler first, which is closer to what's actually going on. Then when learning the C syntax, it all fits into place neatly, rather than being mysterious asterisks and so on.
- mwattsun 5y ago
  I can't imagine being a programmer without starting out by becoming proficient in assembler. It takes a lot of mystery out of programming languages because you know whatever the syntax is it all ends up as branches, calls, stacks, registers and memory accesses.
  - eternityforest 5y ago
    If you want to do embedded I would kind of agree(But C is low level enough), otherwise... I'm not so sure. Low level languages teach a lot of habits I don't like, and they don't teach as much about working in a modern high level environment on complex software. Everyone should probably be vaguely competent with C, but I wouldn't call it a top priority. If you're thinking about the underlying machine stuff when coding in Python, you're kind of just accepting leaky abstractions. If you're in the habit of first principles thinking, leaks seem normal. C doesn't really seem to layer all that well. Whenever I code in C, I usually have to dig down to the SDK API level, and I wind up reading 10 other files to make a change in 1. High level languages make it clear when something isn't DRY, or an abstraction leaks, or something isn't usable without modification. It's unusual, you notice right away, and you want to fix it because it obviously doesn't fit. Low level languages make everything feel totally patched together. Encapsulation just isn't a big thing in most of it. It's almost like looking at an old point to point wired TV set compared to a rack of servers. You might be able to write some amazing ASM code that feels as modern as some top notch Kotlin... but I'd call that an expert, not just a competent person. And worst of all, the compiler can't catch many bugs. It's not like Rust. Or even Python. Low level languages don't teach the art of making sure that the computer has your back, the way Rust might. They normalize just entirely relying on your own skill, to the point where some C devs don't even seem to want the compiler to eliminate large classes of bugs for them. High level languages teach a real appreciation of abstraction and safety, and standardization, that I don't feel like I really learned with C.

flohofwoe 5y ago

When you arrive at the sort of gibberish that you need a tool to make sense of it, it's time to split the declaration into several much simpler typedef building blocks (especially recommended for function types). Also for what it's worth, this isn't 'human readable' either, or is it?: "declare foo as pointer to function (pointer to const void) returning pointer to array 3 of int"

bool3max 5y ago
That seems perfectly readable to me, sans the part in the parentheses.

jbandela1 5y ago

If you are using C++, you can make this a lot easier using this template alias template<typename T> using ptr = T*; ptr<const char> str: const ptr<char> pchar; ptr<void(ptr<const char>)> fun_ptr; Basically this simple trick removes most of the confusion, and you can read the types left to right.

jcelerier 5y ago
It also makes function pointer types much clearer: using func_ptr = float(int); // Given float some_func(int); // Then func_ptr* a = &some_func; // Also func_ptr* b = [] (int x) { return 0.f; };

teddyh 5y ago

You know, you could just apt install cdecl And then do it on the command line. But hey, let's turn everything into a web service, with monitoring as a bonus feature. (Repost of https://news.ycombinator.com/item?id=11164685 https://news.ycombinator.com/item?id=11164685)

marcodiego 5y ago

It would be good if there was something similar for the other constructs, like statements, loops, calls... That would become a "C" to natural language translator. I wonder how hard it is to turn: for(int i = 0; i < x; i++) into "declare 'i' as int and assign '0' to it; while 'i' is smaller than 'x' do ... and increment 'i'."

derw-lang 5y ago

As part of Derw, I've added an English output generator[0], with the idea that the output could be used to improve error messages or help developers understand unfamiliar syntax, particularly for those more used to Javascript rather than ML. Similar concept to cdecl 0 - https://mobile.twitter.com/derwlang/status/1505709982024671238 https://mobile.twitter.com/derwlang/status/15057099820246712...

emmanueloga_ 5y ago

what's stopping a new version of C from defining a better declaration syntax? (better = easier to read, write and understand)

RTFM_PLEASE 5y ago
1) 50 years of backwards compatibility. 2) It is not necessary. C's terse syntax is not hard to understand for anyone who actually uses the language. Most of the comments here are from people who do not.
- xigoi 5y ago
  You can add new syntax without destroying backward compatibility, as long as it doesn't conflict with existing syntax. C++ took C and added the std::unique_ptr<int> syntax, which is much more readable.

mattiii 5y ago

the c pointer syntax is perfectly fine after realize you its just the operator precedence rules but in reverse. int foo, *bar, baz(), (*zyzzy())(); i do not understand why blowhard rob pike types dislike it. its exactly the kind of elegant you would think they would like