Hacker News Reader

Comment by pixie_ | Hacker News Reader

Cool. Does anyone else write their code with the * after the type, instead of before the variable? Like int* x; as opposed to int * x; to me int* is the type of x, so keeping it together makes sense. Like a function returning an int pointer would be - int* myfunction(); or type casting something (int* ). Putting the * before the variable and not as part of the type just seems unintuitive. Anyone else agree/disagree?

edit: another point - putting * before the variable makes me think of a dereferencing operation, and that's part of why putting it before the variable name in declaration is unintuitive, and very confusing to people learning C.

View on HN

This style rests on the premise that C declaration syntax is:

  <type> <space> <name>

It isn't, and using the style is misleading people to think that it is.

You can't write:

  int[10] a;

You write:

  int a[10];

Basically any type that involves more than a base-type and a pointer is going to fail to work with that style, and then you will lose uniformity as well.

There's actually a pretty good reason for the way C syntax is: The declaration and use syntax are virtually identical, and the precedence rules are identical. It's nice to only have to learn that once.

The fact the * before the variable looks like dereferencing is intentional, you're supposed to read this:

  int *x;

as: "Declare the dereference of x to be an int".

And this:

  int (*(*x)(void))[10];

As "The dereference of x is a function of void, the dereference of which is an array of 10 ints".

The declaration and use syntax of pointers is not 'virtually identical.' int* a; could be used to set int* b = a; or int c = * a; or int* d = &a;

Also for arrays it's unfortunate the syntax is like it is, because int a[10];, is of course a pointer and would be a bit more intuitive in the form of int[] a = new int[10];

Also you say * before the variable 'looks like dereferencing is intentional.' but is it really? what's your source?

You are misunderstanding.

I'll start from what you said about arrays:

> because int a[10];, is of course a pointer

This is a common misconception about C.

  int a[10]

defines an array, not a pointer. typeof(a) is int[10], and not (int ptr). The thing is, whenever you take the value of an array in C, it is degraded to a pointer to the array's first element, and this confuses people to no end that arrays are pointers.

For example, if we declare:

  int a[10];
  int *b;

Then sizeof(a) and sizeof(b) are very different. typeof(&a) is pointer-to-int[10], whereas typeof(&b) is pointer-to-pointer-to-int.

  void f(int (*x)[10]) { ...
  }

If you call:

  f(&a); // will type-check
  f(&b); // will not

So the syntax for declaring arrays is fine, and when you declare an array, no pointer is being declared at all.

This is C syntax for type declarations:

  <base type> <type declaration here>

The "<type declaration here>" part uses virtually the same syntax as use syntax.

For example, if x is a pointer to a function that returns a pointer to an array of floats, you could reach a float via this syntax:

  (*(*x)())[1]

You could declare x using this syntax:

  float (*(*x)())[10];

The main differences are:

* Array size instead of index

* There's no requirement to dereference a function pointer to call it, but there is a requirement to use the dereference syntax to declare it.

* Array values can be used as pointers to their first elements (due to the automatic degradation), but must be declared as arrays.

Yes, it is unintuitive. However, there's a reason people do it the unintuitive way, and that's due to the C spec.

  float* foo, bar;

This code declares bar as a float, not a pointer! To make things less misleading, most C programmers have adopted the convention of putting the star next to the variable name instead of the type:

  float *foo, bar;

even though it looks weird.

Yea I am aware of this quirk and just avoid declaring multiple pointers like that because it's confusing just to look at, plus error prone.

I used to have the exact same confusion until I reread K&R just last month.

The idea behind int foo; is that: foo is an int. That is to say: typeOf(foo) == int. So you can still think of as the dereferencing operator.

Personally I would prefer int& foo; since pointers are complicated enough already without the indirection.

I do what you're doing. I do this not because it accurately supposes what C's syntax is (it doesn't; however that doesn't matter because I follow the 1 pointer per line convention), but because it was most common in codebases I've worked on and the notation commonly shown in school.

I totally agree, but it just sounds weird when you say it, JS* vs. *JS.

I have no problem with the name, just wanted to bring up the issue with other programmers. How is it pronounced anyways? starJS, pointerJS, astrickJS?

The emphasis with 'int *x' is that the variable is no longer really a variable anymore. It is a pointer to your variable. It doesn't really have anything to do with the type.

Yes it is still a variable, a variable of type int* , not int. Which can be returned by a function that returns type int* or type casted int* . Variables of type int are assigned numbers, while variables of type int* are assigned memory addresses.

second edit: there's a link on reddit to the c++ coding standard for the joint strike fighter and it says pointers should be written like int* x; for exactly the reasons above. pretty cool - http://www2.research.att.com/~bs/JSF-AV-rules.pdf see section 4.9.6

I've always written it before the variable, as int *x. A pointer to something isn't really a new type, is it?

A pointer to T is definitely a different type to T itself: http://codepad.org/ztUjn7g8

What I mean to say is, if T is a type, then a pointer to T is certainly different from T, but a "pointer to T" isn't a new type. The C type system includes the single type "pointer."

Reply on news.ycombinator.com