For better readable code you should use int *p; because of the alignment of the pointertype.
For example: int* var1, var2;
Here var1 is a pointer and var2 is normal integer. I prefer the int* p1; notation, too. But you should everytime remind the alignment...
Well, int *p; versus is int* p; is very much a matter of taste. I personally find int* p; reads better as I see the int* as the type and p as the variable name.
But then I would never code int* var1, var2; as it breaks the one-declaration-per-line and initialize-all-varaible rules. I would code this as
1 2
int* var1 = NULL;
int* var2 = NULL;
And in general, as a C++ programmer, I use declaration-at-point-of-first-use. That is,
1 2 3 4 5
// other stuff
constchar* name = obg.GetName();
// etc
rather than
1 2 3 4 5 6 7
constchar* name = NULL;
// other stuff
name = obg.GetName();
// etc
So there's not stacks of variables to declare (one row at a time) or initialize at the start of a function in the first place.
If p isn't of type "pointer-to-int" what type does it have? To me it makes very much sense because I like to think that p is a pointer to an int.
Well you can think of it that way, what I'm trying to say is that writing it like int* p implies that there is actually a int* type. This does not exist (think about the type of x in int* p, x;). Saying int *p is clearly defining *p as an int. p doesn't really have a primitive type.
As far as I am concerned, if I write char* p; then the type of p is a char* (or pointer to int). Not everyone buys into this interpretation, but I'm not alone.
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.
Of course, there is no primitive (or built in) type int*. But if I follow the same logic, that only primitive type are actually types, structs and classes (being compound) cannot actually be types, either. This I obviously do not buy into!
And that the statement that char* -- as a type -- does not exist is not a statement of fact. It's just some peoples interpretation.
As is my interpretation that it is a type!
Well, then according to your interpretation of the declaration
const char* p1, s;
it follows that s has type const char*.
* is not a type specifier (it is not an interpretation it is a statement of the C/C++ standard). * is used in a declarator. So it is a good style of programming to separate type specifiers and declarators. For a given type specifier many declarators can be specified in a declaration specifier. So it is more consistent to write
const char *p, s;
where *p and s are declarators and const char is a type specifier
than
const char* p, s;
In fact in the example above you break the grammar of the C++ language.
I can demonstrate you a more interesting example that makes you style senseless. Consider the following declaration
It says only about your bad style of programming because instead of to help reviewers to understand easy all syntactic constructions you say them "it's up to you to remember what happens".
Weak programmers think that only they read their code. More experienced programmers as you think that their code can be read by only C/C++ programmers and "it's up to you to remember what happens". And only profeesional programmers understand that their code can be read by others who does not know C++. And the task of professional programmers is to help these others to understand their code and do not say "it's up to you to remember what happens".
To help the reviewers understand, most C++ coding styles limit the number of object declarations to one per line. Type-centric approach is much more important than compressing the source code.