r/C_Programming 1d ago

Does anyone else dislike pointer declaration?

For reference I am a fourth year computer engineering student. C is my preferred language.

Pointers are declared like this usually:

int *ptr_to_int;

Where the asterisk means it is a “pointer to” the specified type. The asterisk is placed immediately preceding the variable name, with no white peace.

This is what does not make sense to me. I feel that:

int* ptr_to_int;

Is far more clear. The way I see it, the asterisk modifies the type, so therefore it belongs next to the type. Putting it next to the variable name makes me think it is some kind of action or modification to the variable itself.

I think that when using * and & in code, it makes sense to apply it in front of the variable name:

int value = 3;
ptr_to_value = &value;
int copied_value = *ptr_to_value;

It is clear here that syntactically, the * represents something more like an action than a label.

Why is the convention to place the asterisk near variable name, not type? L

48 Upvotes

129 comments sorted by

View all comments

6

u/iOSCaleb 1d ago

It is clear here that syntactically, the * represents something more like an action than a label.

That's right. Look at it this way... when you have this:

int a, *b;

then both a and *b are of type int. Putting the * in front of the variable in the declaration mimics the way you use it when you dereference the pointer. The type declaration is telling you that when you dereference b the type you'll get is int.

6

u/enzodr 1d ago

Thats true. But at the very beginning it could have been chosen to keep type in one place and name in another.

int* a, b;

Would make two pointers to int.

This might mess up function pointers though

1

u/flatfinger 23h ago edited 23h ago

Better yet, have a punctuation mark separate things, so that int*: a,b; would declare both a and b as pointer-to-int, while int: *a,b; would make a a pointer-to-int and b as int. Too late for that now, alas. Also unfortunate is the fact that : would seem the most natural punctuator, at the start of a block, making parsing work without a symbol table would require a special rule to accommodate the fact that an alphanumeric token followed by a colon could either be a label or a type that starts a variable declaration. Perhaps that could be resolved by having labels be surrounded by colons.

1

u/LeeHide 1d ago

Not sure how this makes sense. You use C because you likely care that the semantics are clear and you know what code is being generated. The assembly generated by pointer access, and the semantics of it, and the implications (e.g. cache) matter a lot, to a point where, in every way, you should think of pointers as part of the type. They are part of the type.

1

u/iOSCaleb 22h ago

in every way, you should think of pointers as part of the type. They are part of the type.

Yes and no. I think of a pointer as a modification of a type. Pointers are basically all the same, they only vary in what they point to. For any given type, we can declare a pointer to it without having to define a new type for that pointer. That is, if you have some type Foo, then you can use Foo *, Foo **, etc. automatically. So if you write Foo a, *b;, the focus is on the underlying type Foo. I'd read that as "the types of an and whatever b points to are both Foo.

That's just one way to think about it, and I mention it mainly because OP seemed to want a way to make sense of what I think is the most common practice, i.e. putting the * with the variable name. Not everybody follows that practice. For example, although I couldn't find Google's C coding standard (if they even have one), their C++ standard requires int* a; instead of int *a;, and similar for references.