Declaring Pointers; Asterisk on the Left or Right of the Space Between the Type and Name

Declaring pointers; asterisk on the left or right of the space between the type and name?

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.

Placement of the asterisk in pointer declarations

4, 5, and 6 are the same thing, only test is a pointer. If you want two pointers, you should use:

int *test, *test2;

Or, even better (to make everything clear):

int* test;
int* test2;

Type Declaration - Pointer Asterisk Position

Stroustrup was asked this and he said (paraphrasing)

• if you think more C-ish you will say int *a and Employee *pE
  (so in your head you're thinking "the content of a is an integer")
• if you think more C++-ish you will say int* a and Employee* pE
  (so in your head it's "a is an integer pointer")

You can think however you like, as long as you never declare two
pointers on the same line.

Works for me. I'm an Employee* pE kind of person, but I'm married to an Employee *pE kind of person - my advice would be not to get too worked up about it.

What is the difference between Type *Name and Type* Name?

C compiler ignores the whitespace (except whitespace inside character constants and string literals).

It means that

int    * p;
int*p;
int* p;
int *p;
int        *                                p                      ;

mean exactly the same.

The white space is only important in macros for example:

#define a(x) ((x)+(x))
#define a (x) ((x)+(x))

mean something completely different.

C++ style: Stroustrup' s placement of pointer asterisks

C++ emphasis heavily on types and when it comes to pointers declaration, to avoid any sort of confusion, Bjarne suggested - Stick to one pointer per declaration.

From Bjarne Stroustrup's C++ Style and Technique FAQ [emphasis added]:

Is int* p; right or is int *p; right?

Both are "right" in the sense that both are valid C and C++ and both have exactly the same meaning. As far as the language definitions and the compilers are concerned we could just as well say int*p; or int * p;

The choice between int* p; and int *p; is not about right and wrong, but about style and emphasis. C emphasized expressions; declarations were often considered little more than a necessary evil. C++, on the other hand, has a heavy emphasis on types.

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.

The critical confusion comes (only) when people try to declare several pointers with a single declaration:

int* p, p1; // probable error: p1 is not an int*

Placing the * closer to the name does not make this kind of error significantly less likely.

int *p, p1; // probable error?

Declaring one name per declaration minimizes the problem - in particular when we initialize the variables. People are far less likely to write:

int* p = &i;
int p1 = p; // error: int initialized by int*

And if they do, the compiler will complain.

Whenever something can be done in two ways, someone will be confused. Whenever something is a matter of taste, discussions can drag on forever. Stick to one pointer per declaration and always initialize variables and the source of confusion disappears.

See The Design and Evolution of C++ for a longer discussion of the C declaration syntax.

clang-format: Align asterisk (*) of pointer declaration with variable name

It's fixed now!

The review https://reviews.llvm.org/D27651 has been re-applied in https://reviews.llvm.org/D103245 and committed in https://reviews.llvm.org/rG3e333cc82e42e1e2ecc974d896489eebe1a5edc2.

This change will be included in LLVM 13 release.

Why is the asterisk before the variable name, rather than after the type?

They are EXACTLY equivalent.
However, in

int *myVariable, myVariable2;

It seems obvious that myVariable has type int*, while myVariable2 has type int.
In

int* myVariable, myVariable2;

it may seem obvious that both are of type int*, but that is not correct as myVariable2 has type int.

Therefore, the first programming style is more intuitive.

What is the difference between `char **argv` and `char** argv`?

If so, then what is char** argv?

If (also) declares argv to be a pointer to a pointer to a char.

What is the difference between char **argv and char** argv?

The difference between them is the placement of space. There is no other difference. These are also the same:

char**argv

char                         *  *   argv

char
*
*
argv

The asterisk in Objective-C object instance declarations: by the Object or by the instance?

It doesn't make a difference, but there are good reasons to put it in each place:

• It makes sense to put it near the class, because that makes it feel like a type: NSString*, a pointer to a string. Sensible.

• It makes sense to put it near the variable, because that's what's actually happening: * is dereference. When you dereference your pointer string, you get an NSString. *string is an NSString. Sensible.

You may want to go with the latter because that's the way the compiler is thinking, so: NSString* oneString, anotherString will not work, whereas NSString *oneString, *anotherString is correct.

---

Related Topics