3

I am struggling with understanding the correct pointer syntax, various sources seem to be doing it differently.

Which one of these is correct?

int* p = NULL;
int * p = NULL;
int *p = NULL;

and these?

*p = &x;
* p  = &x;

Sorry for the beginner question but I can't seem to find a straight answer.

Does the * goes right after the data type, right before the var name or in between?

Emil Laine
  • 41,598
  • 9
  • 101
  • 157
Big Fas
  • 33
  • 2
  • Possible duplicate of [Placement of the asterisk in pointer declarations](http://stackoverflow.com/questions/180401/placement-of-the-asterisk-in-pointer-declarations) – Emil Laine Jan 29 '16 at 16:28

3 Answers3

2

All are valid, and have the same meaning, so it's a matter of personal choice.

The one thing to beware of is this:-

int* i,j;

Despite appearances this declares i as a pointer to int, but j is just an int. See this question here for details. If really you want this, use..

int *i;  
int j;

Or, if you insist on having them on one line

int j, *i;
Community
  • 1
  • 1
Roddy
  • 66,617
  • 42
  • 165
  • 277
  • Thanks for the explanation, although I've never mixed type declaration this example gives me the idea that, also in single variable declaration, the pointer star should be always attached to the variable name and not to the type! – merosss Jul 08 '14 at 13:07
0

This is more a question of grammar, as to which is "correct", as all are valid.

Think about what the declaration/code describes and join them accordingly.

e.g.

"I want an int pointer called p" implies: int* p

"I want to the contents pointed to by p to contain the address of x" implies: *p = &x

You want to pick a standard that is easy for others to read, and/or is in popular use, to make the transition into new commercial development sites easier. They will all have similar coding standards.

iCollect.it Ltd
  • 92,391
  • 25
  • 181
  • 202
  • If you must down-vote, please explain why. This site is not meant to be a popularity contest :) – iCollect.it Ltd Jul 13 '12 at 09:07
  • because what you declare as an implication is an arbitrary personal opinion. What about "You want an *int array of size 2* -> implies `int[2] a;`". – Johannes Schaub - litb Jul 13 '12 at 09:41
  • @Johannes Schaub - litb: That was a simple guideline for the very simple cases shown. Commonsense and language syntax also apply. *Otherwise we would be writing code in a natural language, rather than using all sorts of artificial delimiting.* – iCollect.it Ltd Jul 13 '12 at 09:47
0

All of them are correct. Whitespace between operators, between names and operators etc is not relevant.

Do it the way it is most readable to you.

Johannes Schaub - litb
  • 496,577
  • 130
  • 894
  • 1,212
  • 1
    Actually I would always recommend you *"do it the way that is most readable to others"*. This will avoid clashes with commercial coding standards at existing businesses. – iCollect.it Ltd Jul 13 '12 at 09:08
  • @HiT that is a weird recommendation. you meed to read your code and your colleague his code, generally. if you wanna have a single coding convention, that is a different matter. but coding so that it is readable to random other people is not useful. – Johannes Schaub - litb Jul 13 '12 at 09:26
  • That is a very odd response. Most teams will peer-review code before check-ins and maintenance coding (i.e. reading other people's code) far exceeds new coding in commercial environments. Most commercial sites will have similar standards to each other. They do not for instance encourage `int * p`. I am simply saying that "do it your own way" is not appropriate in an industry where common standards already exist. There is nothing random about your target audience :) – iCollect.it Ltd Jul 13 '12 at 09:30
  • @HiT as i said that is a valid reason for a shared coding convention. but if you dont have a shared coding convention (which would not be good) coding with your colleagues habit is no good. also "others" have a heterogenous set of coding conventions. what one will you choose? the one of your one colleague or of the other colleague? – Johannes Schaub - litb Jul 13 '12 at 09:34
  • Perhaps I did not explain clearly in my first comment. I am not talking about individuals when I say "others". Again I simply say *"do it your own way"* is never the best approach. – iCollect.it Ltd Jul 13 '12 at 09:42