Sign in to follow this  

[c++] Why do you write "int *number" instead of "int* number"?

This topic is 2959 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Its a personal choice, and not a very important one. I used to write "int * number", because I like whitespace. But for quite a while now I just attach the asterisk to the variable name. No particular reason.

That is, when I use raw pointers at all, which I try to minimise.

Share this post


Link to post
Share on other sites
Some people (like I) prefer to place the * next to the type to enforce the idea of the pointer being of that type.

int* VariableName.

Share this post


Link to post
Share on other sites
I put the asterisk next to the type (int* p) because I think and read it like "p is an int-pointer (int*)". Some will put it next to the variable instead (int *p) and read it like "p is a pointer(*) to an int".

I've found it's easier to be consistent when putting the asterisk next to the type and treating it as a single type, for instance:
Foo* p = reinterpret_cast<Foo*>( pOther );


But there's no right or wrong. It comes down to individual preference.

Antheus: I would never want to write ambiguous code like that. Here's how I would declare two subsequent pointers of the same type:
int* x;
int* y;

Furthermore I wouldn't declare pointers without directly initializing them i.e. have them point at something in memory, or NULL.

The most common case for me is to use pointers as arguments in function headers, where the position of the asterisk makes no significant difference.

Share this post


Link to post
Share on other sites
I think it is better to write the * near the name because it is more easelly to spot weather the var name is a pointer or not;

take the following example:

type* a,*b;

you may be tempted to believe that a and b are of different types when you fly with your eyes on the code.

It is still a personal choice.

Raxvan.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
int* x, y;


What is x, what is y?


x is a pointer to an int.
y is an int.

That is why the asterix should go with the identifier (in this case), so that people don't make the mistake of thinking they're both pointers, like:

int *x, y;

In other cases, if they're seperated:

int *x;
int y;

it doesn't matter so much, but i think 'type *identifier' is a good habit to have.

Share this post


Link to post
Share on other sites
Quote:
Original post by Makaan
I think it is better to write the * near the name because it is more easelly to spot weather the var name is a pointer or not;

take the following example:

type* a,*b;

you may be tempted to believe that a and b are of different types when you fly with your eyes on the code.

It is still a personal choice.

Raxvan.


I agree that's personal choice. I try though not to define many variables in one line for clarity's sake.

Share this post


Link to post
Share on other sites
I do prefer int* x to int *x as I like the idea of having the type on one side, but technically the grammar of C/C++ isn't like that. Consider for instance int* x, y, which means one pointer to an int and one int are declared...

At the end of the day int * x would probably win in the consistency category. Especially when you start applying qualifiers like int*const* x where the no space version will look ugly regardless...

It boils down to preference, this is one silly thing that can trigger edit wars in code among people who believe their version is better.

Share this post


Link to post
Share on other sites
Quote:
Original post by supamike
Quote:
Original post by Antheus
int* x, y;


What is x, what is y?


x is a pointer to an int.
y is an int.

That is why the asterix should go with the identifier (in this case), so that people don't make the mistake of thinking they're both pointers, like:

int *x, y;

In other cases, if they're seperated:

int *x;
int y;

it doesn't matter so much, but i think 'type *identifier' is a good habit to have.


I disagree with you.

int is a type (integer)
int* is another type (a pointer to an integer)
what is "int space"? (or int * number)

Share this post


Link to post
Share on other sites
Quote:
Original post by Beyond_Repair
I do prefer int* x to int *x as I like the idea of having the type on one side, but technically the grammar of C/C++ isn't like that. Consider for instance int* x, y, which means one pointer to an int and one int are declared...

At the end of the day int * x would probably win in the consistency category. Especially when you start applying qualifiers like int*const* x where the no space version will look ugly regardless...

It boils down to preference, this is one silly thing that can trigger edit wars in code among people who believe their version is better.


I agree with you.

But all books/websites/samples usually use int *number.

BTW, thanks a lot for replies, I thought I was the only one using int*

I guess in a team, int * number is the best one, as you said, just to avoid team problems.

Share this post


Link to post
Share on other sites
std::vector<int> numbers;

boost::shared_ptr<int> number(new int(0));

void foo(int &number) {
number = number * number;
}

std::auto_ptr<int> bar() {
return std::auto_ptr<int> (new int(0));
}


What is this '*' symbol you keep using when declaring a variable? You can't multiply types by identifiers! :)

edit: on a serious note, I usually put the '*' by the variable name as you can see in my foo function when I put the '&' by the variable name.

Share this post


Link to post
Share on other sites
Quote:
Original post by ricardo_ruiz_lopez
what is "int space"? (or int * number)

What is "unsigned int"? (Yes, it is its own type)

Now let's discuss tabs vs. spaces.

Share this post


Link to post
Share on other sites
Quote:
Original post by ricardo_ruiz_lopez
Quote:
Original post by supamike
Quote:
Original post by Antheus
int* x, y;


What is x, what is y?


x is a pointer to an int.
y is an int.

That is why the asterix should go with the identifier (in this case), so that people don't make the mistake of thinking they're both pointers, like:

int *x, y;

In other cases, if they're seperated:

int *x;
int y;

it doesn't matter so much, but i think 'type *identifier' is a good habit to have.


I disagree with you.

int is a type (integer)
int* is another type (a pointer to an integer)
what is "int space"? (or int * number)


You can disagree if you want but the C++ standards for:

int* x,y;

only gives you one pointer (x is a pointer, y is not).

The rules about how that markup works means that the * is a modifer of the variable, not of the type.

So it seems much more appropriate to put the * next to the var name.

int *x,*y; //the right way to declare two int pointers

That's what i think but of course, people normally put it next to the type for some reason i can't fathom. Maybe it's the "wish" that the * was a modifier of the type, not the variable.

It definitely seems like that SHOULD be the behavior, but it isn't :P

Share this post


Link to post
Share on other sites
Quote:
Original post by Atrix256
You can disagree if you want but the C++ standards for:

int* x,y;

only gives you one pointer (x is a pointer, y is not).

The rules about how that markup works means that the * is a modifer of the variable, not of the type.

So it seems much more appropriate to put the * next to the var name.

int *x,*y; //the right way to declare two int pointers

That's what i think but of course, people normally put it next to the type for some reason i can't fathom. Maybe it's the "wish" that the * was a modifier of the type, not the variable.


You can also construct an example that shows that the "*" clearly belongs to the type, not the variable:
typedef int   INT;
typedef int* PINT;

PINT x, y;
IMO, seeing a "pointer to int" is a distinct type to "int", it really belongs closer to the type, even if that can cause you to make an occasional mistake when using comma (an error which you'll get told about at compile time anyway!).
//the right way to declare two int pointers:
int* x;
int* y;

Share this post


Link to post
Share on other sites
Quote:
Original post by Beyond_Repair
At the end of the day int * x would probably win in the consistency category. Especially when you start applying qualifiers like int*const* x where the no space version will look ugly regardless...


That's the very reason why I use a space before and after "*".

Share this post


Link to post
Share on other sites
Quote:
Original post by ricardo_ruiz_lopez
Quote:
Original post by supamike
[...]
it doesn't matter so much, but i think 'type *identifier' is a good habit to have.


I disagree with you.

int is a type (integer)
int* is another type (a pointer to an integer)
what is "int space"? (or int * number)
I disagree with your disagreement :P

The language applies the * qualifier to the variable, not the type.

By pretending that int* is a type on its own, you create a model of your programming language in your mind that diverges from how things actually are.

Same goes for const. Will this compile?

const int *i = 0, *j = 0;
j = i;
The answer is yes, because the type is not const int or const int *, but int. So i is const and j isn't.

If you instead read "int" as saying "the following variables are variants of the type int", it becomes clearer.

int *const i = 0, *const j = 0;
j = i;
Of course you can decide to completely avoid multiple variable declarations in a single statement. In which case it is all a matter of personal preference.

I prefer to have the code look the way the language will interpret it as much as possible. Though I do wish that they had designed it the way you seem to want it with qualifiers belonging to the type instead of the variable.

Share this post


Link to post
Share on other sites
Quote:
Original post by Cygon
Same goes for const. Will this compile?

const int *i = 0, *j = 0;
j = i;
The answer is yes, because the type is not const int or const int *, but int. So i is const and j isn't.


No, both i and j are non-const pointers to const int. That means you can still assign other addresses to i and j, but you can't modify the pointee.

If you want i and j to be const pointers to whatever cv-qualified entites, you have to put the const qualifier on the right:

int const * const p = &x; // const pointer to const int
int * const p = &x; // const pointer to non-const int
int const * p = &x; // non-const pointer to non-const int


To make the babel complete, const and volatile are distinct but not exclusive:

int main () {
int x;
int const * const a = &x; // const ptr -> const int
int * const b = &x; // const ptr -> int
int const * c = &x; // ptr -> const int
int volatile const * const d = &x; // const ptr -> const volatile int
int volatile * const e = &x; // const ptr -> volatile int
int volatile const * f = &x; // ptr -> const volatile int
int const * const volatile g = &x; // const volatile ptr -> const int
int * const volatile h = &x; // const volatile ptr -> int
int const * volatile i = &x; // volatile ptr -> const int
int volatile const * const volatile k = &x; // const volatile ptr -> const volatile int
int volatile * const volatile l = &x; // const volatile ptr -> volatile int
int volatile const * volatile m = &x; // volatile ptr -> const volatile int
int volatile * n = &x; // ptr -> volatile int
int * volatile o = &x; // volatile ptr -> int
int volatile * volatile p = &x; // volatile ptr -> volatile int
}


Yay.

It's easier by the way if you read right to left (e.g. the last one: p is a volatile pointer to volatile int), using above writing style.

[Edited by - phresnel on November 9, 2009 2:18:20 AM]

Share this post


Link to post
Share on other sites
int* x, y;
float a,b,c;

Do people really write this kind of code?
Declaring multiple variables (uninitialized) on the same line?
I don't. I find it kind of lazy and uninitialized variables look dirty to me.

Share this post


Link to post
Share on other sites
Quote:
Original post by phresnel
Quote:
Original post by Cygon
Same goes for const. Will this compile?

const int *i = 0, *j = 0;
j = i;
The answer is yes, because the type is not const int or const int *, but int. So i is const and j isn't.


No, both i and j are non-const pointers to const int. That means you can still assign other addresses to i and j, but you can't modify the pointee.


Whoops, you're right, of course.

Make that

int*const i = 0, *j = 0;
j = i;
The point is, the * and const belong to the variables in C++, so only i has the const qualifier applied to it.




Share this post


Link to post
Share on other sites
Quote:
Original post by Scarabus2
*** Source Snippet Removed ***
Do people really write this kind of code?
Declaring multiple variables (uninitialized) on the same line?
I don't. I find it kind of lazy and uninitialized variables look dirty to me.


Agree on initialization, no agree on declaring multiple variables. No sane reasoning, just matter of taste:

const float
foo = x,
bar = sin (foo),
fooboo = cos (sqrt (bar) * foo)
brob = bar * fooboo + 1.f
;


I find that more readable and less error prone w.r.t. const correctness than
const float foo = x;
const float bar = sin (foo);
const float fooboo = cos (sqrt (bar) * foo);
const float brob = bar * fooboo + 1.f;


Plus it supports my lazyness, yes :D

Share this post


Link to post
Share on other sites
Just to add some food for thought to those that think * doesn't belong to the type, then what the **** is:


X<int*> x;


(Not to say that I have strong feelings for any syntax, this might be one of the things that leads C++ programmers to think of int* as a type of its own, rather than pointer to type.)

Share this post


Link to post
Share on other sites

This topic is 2959 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this