That misses the point of the C declaration syntax: you write an expression that when used on its own will recover the basic type. So the asterisk goes with the symbol name, because that's how you dereference a pointer.

Further, it doesn't work if you want to declare more than one pointer like so:

  int* a, b;  /* wrong */
  int *a, *b; /* correct */

One way to create a pointer type in C would be to declare it using typedef:

    typedef int * int_p;

    int_p p, q, r;

    int* p, *q, *r;

    int* p;
    int* q;
    int* r;

I have seen some code that strikes a middle ground:

    int * p;

So why don't C++ programmers use typedef? I don't know, other than I understand Stroustrup doesn't like it (not without reason).

(Edited for formatting and minor clarity corrections.)

It's not really a big deal because things are also always introduced at the latest possible position. Each is also typically given an initializer. I'd consider it suspicious if I were to see C++ that declared 3 uninitialized pointers back to back like this.

And then you get to the codebases where the authors have chosen to embrace auto and type inference... :)

For example, sizeof(x) takes a type. The type argument for sizeof(int) is different than sizeof(int* ) and the results are different. sizeof(int*[3]) is different as well. These are all different types where pointers change the type. It's not the same type with a pointer modifier, there is no such thing.

The C++ syntax is the same as C in this regard: a declaration has specifiers, and then one or more declarators.

The exception are function parameters, where you have (at most) one declarator.

> why don't C++ programmers use typedef?

C++ programmers do use typedef. For instance:

  typedef std::map<from_this_type, to_this_type> from_to_map;

When a C++ class/struct is declared, its name is introduced into the scope as a type name. Therefore, this C idiom is not required in C++:

  typedef struct foo { int x } foo;

  typedef class x { x(); } y;

  y::y() // cannot write x constructor this way
  {
  }

    f(int &a);

The verbose one. A few extra lines rarely matters. I think the number of times this has come up in my code base is very very small, maybe a few dozen extra lines across hundreds of thousands.

Typedeffing pointers, especially for the sole purpose of "being less verbose" when declaring uninitialized pointers, is a red flag too.

But we're in 2020 and we've learned to avoid to declaring stuff without initializing it at the same time to avoid the stupid mistake of using something uninitialized.

Interestingly enough, testing with clang shows that uninitialized variables get their warning, but uninitialized raw pointers don't.

Yes. It just looks better IMO. Now, east-const vs west-const?

    int* a, b;  /* wrong */
    int *a, *b; /* also wrong */


    /* correct */
    int* a;
    int* b;

    int* a, b;  /* wrong */
    int *a, *b; /* also wrong */


    /* correct */
    int* a;
    int* b;

    /* moar correct */
    int* a{nullptr};
    int* b{nullptr};

A ``typical C programmer'' writes ``int p;'' and explains it ``p is what is the int'' emphasizing syntax, and may point to the C (and C++) declaration grammar to argue for the correctness of the style. Indeed, the binds to the name p in the grammar.

A ``typical C++ programmer'' writes ``int p;'' and explains it ``p is a pointer to an int'' emphasizing type. Indeed the type of p is int. I clearly prefer that emphasis and see it as important for using the more advanced parts of C++ well.

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

If the cast is not there, it will tell you that there is a type mismatch.

I read the first as 'a struct of type Bark pointer named p_dog'.

How do you read the second example in your head?

Also, a take from Stroustrup since I found it. https://www.stroustrup.com/bs_faq2.html#whitespace

    void *(*foo)(int *);

( Taken from https://www.cprogramming.com/tutorial/function-pointers.html )

The whole "declaration follows usage" is just a bad tradeoff. It makes it easier to parse expressions. That's my understanding of why they did it. It makes it _objectively_ harder to read, because some declarations follow this easy pattern of "name on the right and type on the left", while for some other declarations you have to employ the spiral reading pattern (e.g. for function pointers, arrays, with variable declarations being the easiest one).

You know what's easier that all that? Type on the left, name on the right.

  int a;
  int* a;
  int[] a;
  unsigned int(int) f;

That's why Java, Go and D changed this nonsense. Java supports both "int[] a" vs "int a[]". They support both to appease everyone, but they went the extra mile to support "int[] a". D changed it to "int[] a" and called it a day and Go introduced this novel [5]int syntax, which is different, but clearly easy to read ("array of five int").

Again, type on the left, name on the right (or in Go's case, name on the left, type on the right - but at least it's not a mixed bag). Once you see it that way (i.e. you give up on declaration follows usage rule), it's not weird, it's not wrong, it's intuitive, and it makes the language easier to learn and use.

I thought this is a matter of preference until I actually wrote a C compiler for fun and have permanently solidified my opinion on this issue.

The asterisk is part of the type, it's not just some random symbol, it's not a type qualifier like 'const' or 'volatile'. It's a type token that builds a distinct type, e.g. "int * * " is a type that spells "pointer to pointer to int", it's not an 'int' type with some flags attached to it.

Let's take the concrete example of 'struct Bark* p_dog'.

A typical compiler will tokenize 'struct', 'Bark', '* ' and 'p_dog' and will group them as ('struct', 'Bark', '* ') to derive the type "pointer to struct Bark" and ('p_dog') to derive the name of the symbol when it adds an entry into its symbol table, in other words - the compiler itself splits that line so that types are the left, and names on the right.

I wrote C for a long time before I ever even heard of the spiral rule. I do think that the "declaration follows usage" idea worked a lot better before C declarations became so complex. I'm not claiming that the C declaration syntax is wonderful, it isn't. I just think that the C++ style of pretending that int* is a pointer type is misleading, since that's not really what's happening grammatically. Yes, * is a type token, as you say, but it modifies the identifier, not the type specifier. But since the style now is to only declare one variable per declaration, and to always initialize it, then in practice it isn't actually all that confusing.

I have always wanted to write a compiler and I'm sure I would get a new perspective on these matters if I did. Go has done a lot to clean up C's messes. I haven't used it much, but I'd like to know it better.

Because C makes that tradeoff,

  int *a;

  int* a;

For C programming to be pleasant, you have to understand and agree with the philosophy at least while you're writing C.

Go developers changed this in a particularly elegant way. Here's what Rob Pike has to say: https://blog.golang.org/declaration-syntax.

I too gained a better understanding of the problem after going through a compiler-writing exercise.

    int *a, b;

Indeed, Linus Torvalds has a recent rant about people still adhering to max 80-column width code. It's pointless in the day of massive monitors.

It's not pointless unless you're using your massive monitor like you did your tiny one thirty years ago. I use mine like a bunch of tiny monitors, not one big one.

  struct Bark * p_dog = p_cat;