165

Possible Duplicates:
What makes more sense - char* string or char *string? Pointer declarations in C++: placement of the asterisk

I've seen mixed versions of this in a lot of code. (This applies to C and C++, by the way.) People seem to declare pointers in one of two ways, and I have no idea which one is correct, of if it even matters.

The first way it to put the asterisk adjacent the type name, like so:

someType* somePtr;

The second way is to put the asterisk adjacent the name of the variable, like so:

someType *somePtr;

This has been driving me nuts for some time now. Is there any standard way of declaring pointers? Does it even matter how pointers are declared? I've used both declarations before, and I know that the compiler doesn't care which way it is. However, the fact that I've seen pointers declared in two different ways leads me to believe that there's a reason behind it. I'm curious if either method is more readable or logical in some way that I'm missing.

Community
  • 1
  • 1
jakogut
  • 4,409
  • 6
  • 29
  • 41

6 Answers6

150

It's a matter of preference, and somewhat of a holy war, just like brace style.

The "C++" style

someType* somePtr;

is emphasizing the type of the pointer variable. It is saying, essentially, "the type of somePtr is pointer-to-someType".

The "C" style

someType *somePtr;

is emphasizing the type of the pointed-to data. It is saying, essentially, "the type of data pointed to by somePtr is someType".

They both mean the same thing, but it depends on if a given programmer's mental model when creating a pointer is "focused", so to speak, on the pointed-to data or the pointer variable.

Putting it in the middle (as someType * somePtr) is trying to avoid committing to either one.

informatik01
  • 16,038
  • 10
  • 74
  • 104
Tyler McHenry
  • 74,820
  • 18
  • 121
  • 166
  • 18
    I put a space around the `*`, but it is not to avoid committing. My emphasis is definitely on types, but I view it as a modifier of a type. Similar to how we don't say `intconst` but `int const`. The "spaces all around" version also seems to read better when you have `const` in play. `int const * const p;` vs `int const* const q;` (or perhaps the minimal spaces people would prefer `int const*const r;`?) – David Stone Oct 19 '13 at 02:53
  • 73
    I can understand putting the space on both sides using your rationale, still I'd avoid it. Makes the whole thing look too much like multiplication to me. – Edwin Buck Oct 17 '14 at 15:04
  • Conventionally speaking, we define variables using `type name = val;` so one could more succinctly state that `someType* somePtr` follows this convention more accurately where `someType*` is the type [of pointer] and `somePtr` remains to be the name. We do something similar for arrays when we go to place the square brackets on the type side as well (i.e. `byte[]`). But to be honest, if you were to ask me how I write my pointers, I'd say I currently still prefer to write them as `someType *somePtr` :) To each his own... – Matt Borja Apr 21 '15 at 19:31
  • 1
    Besides variable declaration, the same debate applies to typedefs too of whether the pointer logically belongs with type or the thing being defined... (a) `typedef Cat *CatPointer;` (b) `typedef Cat* CatPointer;` When writing a typedef the other order via "using" though, it becomes clearer which word the asterisk belongs with in a typedef, since the first one works, and the second is uncompilable nonsense. (a) `using CatPointer = Cat*;` (b) `using *CatPointer = Cat;` – Dwayne Robinson Dec 18 '15 at 04:26
  • 48
    I do prefer `someType*`, and always use it when declaring parameters. **However** there is a good logical argument against this style when declaring fields. Because to someone not used to C++ the declaration `someType* value1, value2;` will almost certainly be interpreted as both `value1` and `value2` being pointers. (Only `value1` is a pointer.) In short the asterisk isn't a modifier on the type specifier itself, but has to be applied to *each* variable, so it belongs on the variable. Unfortunately I still find `someType*` much easier to read. :( – AnorZaken Jul 29 '16 at 16:55
  • 1
    `the type of data pointed to by somePtr is someType` -> How would you read `someType * const somePtr` then? Noting that `const` is a modifier to `*`, not the variable. You can't say "the type of data pointed to by a constant variable somePtr is someType". There goes your ambiguity. "The type of somePtr is a constant pointer-to-someType" is the only one consistent. Saying the "the type of data constantly pointed to by variable somePtr is someType" is also a little off already. It's no longer about the parameter being declared as constant. – konsolebox Aug 12 '16 at 21:56
  • The latter simply does not **directly** describe the parameter itself. If you're used to imagining how it equivalently works in assembly or in the machine itself, it would be more confusing. – konsolebox Aug 12 '16 at 22:09
  • I have C# and Java background. In these languages, identifier must be an atom, not prefixed by anything else. Therefore I prefer `type* id`. – Gqqnbig May 18 '19 at 22:29
  • I've surfed the internet for a while and personally to me this explanation is the best one! – Kaiyaha Oct 10 '20 at 21:27
  • @AnorZaken I always personally used `someType * ptr`... problem with this is `someType * ptr1, * ptr2` triggers my OCD. Naturally, `someType *ptr1, *ptr2` looks better to me, and now I feel compelled to only use `someType *ptr`... – Evan Hendler Jul 23 '21 at 13:45
  • I like for example `char* argv[]`. My model is that I could use `char argv[]` if I have an array of chars, and if I could use `string` it would be `string argv`, so in this case `char*` is a synonym for string (I think of it as "multiple chars"). – Dan P. Nov 24 '22 at 23:51
134

It doesn't matter. Someone will now come along and close the question as a dupe, and someone else will show how the int* a way breaks if you declare multiple variables in the same declarations while int *a better reflects the syntactical structure of the code, and another one will show that Stroustrup prefers the int* a way and keeps the type together on the left side.

Many opinions, but no "right" way here.

Johannes Schaub - litb
  • 496,577
  • 130
  • 894
  • 1,212
  • 5
    I'm not sure but isn't there an actual pragmatic reason related to how the language grammar creates the parsing of the asterisk ? If I think of function pointer declaration (`rt (*f) ()`), and multi variable declaration (`t *a, *b`), I'm enclined to believe that the asterisk qualifies the identifier at its **right**, similar to like `const` in fact qualifies the identifier at its left (except when first in the statement). – v.oddou Feb 25 '16 at 08:46
  • @v.odd that argument is what I summarized as "the int *a way better reflects the syntactical structure" :) however the purpose of writing good code is not to somehow imitate the grammar used in the Standard. First and foremost code should work and be maintainable you can argue. – Johannes Schaub - litb Feb 25 '16 at 09:52
  • 1
    agreed. but it helps to know the rules to remember how to write stuff when it becomes a bit contrived. Also there is the school of asterisk in the middle `type * var` people who claim it makes sense because const is not written stuck to identifiers either. `type const*const v;` or `type const* const v;` or `type const *const v;` they choose: `type const * const v;` spaces everywhere, this way no preferential treatment. – v.oddou Feb 26 '16 at 01:56
  • 2
    @v.oddou The asterisk is not a qualifier like `const`. The qualifier belongs to the type specifier (it is not a matter of syntax, but grammar, btw.), while the `*` is part of the declarator. Also writing `int *p;` ressembles the later usage. Or does anyone write `* p`? Last not least: there are coding standard which enforce the `int *p` variant, but I have yet to see one which requires one of the the others. And the argument about `int* p, q;` giving the wrong visual impression is imo quite strong. So, if one writes `int *p, q;`, why write `int* p;`? Be consistent! – too honest for this site Jan 10 '17 at 02:26
  • 1
    I was convinced that `int *a` was better than `int* a` but then I have a function with `int* restrict a` but `int restrict *a` does not work. – Z boson Mar 23 '17 at 11:44
70

It doesn't matter, it is personal preference.

Some people like to keep the type together:

int* p;

Other people say that it should go next to the variable because of the following:

int *p, x;//declare 1 int pointer and 1 int
int *p, *x;//declare 2 int pointers.

Over time you will just overlook this and accept both variations.

Brian R. Bondy
  • 339,232
  • 124
  • 596
  • 636
  • 10
    Yes, this was the case that helped me choose `int *p` over `int* p`. To me, this means the asterisk has a relationship with the identifier. – Shammel Lee Nov 11 '17 at 19:53
36

The difference arose because C++ added a stronger type system on top of C.

C style

A C programmer usually thinks in terms of "values," so

int  *pValue;

reads "the dereference of pValue is an int".

C++ style

Whereas a C++ programmer thinks in "types" so

int* pValue;

reads "the type of pValue is pointer to int".

The compiler sees no difference at all of course. However you will find that it is the C programmers who insist on "value semantics" when programming in C++.

informatik01
  • 16,038
  • 10
  • 74
  • 104
Lance Diduck
  • 1,513
  • 9
  • 11
  • 1
    Only for this one, narrow, unconventional definition of "value semantics". For the common definition, i.e. that returning and passing by value are to be preferred wherever possible/practical, then that's definitely a C++ thing. C++ has progressively added numerous features to promote by-value semantics, whereas C doesn't have any except the _as-if_ rule, & this tends to encourage people to pass by pointer. – underscore_d Jun 04 '17 at 20:19
25

I think putting the asterisk adjacent to the name of the variable is clearer.

You might mistakenly declare someType* one, two; thinking that they are both pointers but only the variable one is a pointer; two is just a someType. Declaring as someType *one, *two avoids this problem.

dteoh
  • 5,794
  • 3
  • 27
  • 35
  • 1
    Ok but the first time you type `two->doSomething()` you will instantly see the error you made in any modern IDE so this really isn't a big deal. – Andreas Oct 20 '17 at 06:25
  • 8
    @mrt your argument only holds true if the type is one that has members; If the type is a scalar like `int` or float, there are no members to call. – Shammel Lee Nov 11 '17 at 20:00
  • 6
    @ShammelLee Yes you got a point a there! Haven't thought about simple types when I gave this comment. – Andreas Nov 13 '17 at 05:32
0

Every single way I've seen ever is

TheType *myPointer

because you are declaring a POINTER of type TheType. Similar declaring

TheType myVar

would be declaring an instance variable of type TheType.

Also you can then clearly do this and have it easily readable

TheType myVar, *myPointer;
RivieraKid
  • 5,923
  • 4
  • 38
  • 47
Driss Zouak
  • 2,381
  • 2
  • 26
  • 39
  • 7
    I've seen it this way too; however, I never liked the commonly repeated rationale. In my mind a pointer is a _type_ so it goes with the rest of _the type_ just like the const modifier does. Type in parenthesis "(const char*) var" is marginally a better type format than "(const char *)var". Also most of the explanations fall apart in one area or another. Declarations favor putting the star next to the variable name, but casting favors star next to the type name (if your are writing for ease of readability. It's one of C's as-a-written-programming-language inconsistencies. – Edwin Buck Oct 17 '14 at 15:01