Position of the star in a pointer declaration. Poll

[toglia]

A few days ago I was disusing with a friend where was the correct position of "*" in a pointer declaration:
1) Pointer* variable;
2) Pointer *variable;

When I started programming I used number 2, for some years now I use number 1, which I think its more explicit.

So, I was just curious where did you guys put it!

EDIT: I Added the two missing options...

[toglia]

Right. I thought of it that way too, and it makes a lot of sense. But for some reason you can still find it the other way in official code of big names like the Qt and Msdn, just to name a few.
Example:
http://doc.trolltech.com/4.6/animation- ... dow-h.html
http://msdn.microsoft.com/en-us/library/145yc477.aspx
First things I found...

[Kojack]

This declares... what? It's type information has been moved to its variable. No more clear rule: type then variable.

How is that not "type then variable"? The string and pointer are still on the left, therefore type is before the variable. It's not string ptr*

[Klaim]

I don't care.


I can read both without a problem.


When I write, I use 1) until i'm in a case where 2) is more explicit (there are some cases).

[nikki]

Code: Select all

int** * *** * *** *ptr;

[Kojack]

Looks like morse code.
** * *** * *** * would be: IESESE

[jonim8or]

I guess

Code: Select all

string str;
string *pstr;
string **ppstr;

is saying:
str, (*pstr), and (*(*ppstr)) will give you a string.
in the same way as

Code: Select all

string* *ppstr;

says (*ppstr) will give you a string-pointer.

So the question is, what do you find the most important information? that pstr is a string-pointer, or that (*pstr) is a string?

[betajaen]

After many years of C++ programming, it's very inconsistent to me. I don't think there should be any whitespace between the * and type. Because the * indicates the type. I would go as far as saying, unless it's in a list it should be syntax error to have it any other way.

Then you have things like this:

Code: Select all

const type&
void myClass::functionName() const;

Shouldn't the const go before the functionName?

Code: Select all

void myClass::const functionName();

I like C++, but it should be more rigid in design.

[CABAListic]

I like C++, but it should be more rigid in design.

Agreed. (not necessarily on the const before the function name, because imho that looks weird, but on the point in general )

This could also do wonders for compile time if the syntax were less ambiguous.

[betajaen]

It does look a little weird:

Code: Select all

class aClass
{
  public:
   
   const Ogre::Vector3 const getPosition();

};

But it's more consistent.

[CABAListic]

You could also do it the other way around to achieve consistency (and this is actually valid C++):

Code: Select all

Ogre::Vector3 const getPosition() const;

[betajaen]

Thing is then; If you can do this:

Code: Select all

Ogre::Vector3 const getPosition();

Which is const the getPosition or the Vector3? Not from a C++ point of view, but a more generic one. Which one is const?

[Zonder]

Maybe they should develop a strict mode like they did for html. You declare at the top of your source file the coding standard and then it can use a an optimized compiler instead and ofcouse there wouldn't be all these variances in code layout

[CABAListic]

Thing is then; If you can do this:

Code: Select all

Ogre::Vector3 const getPosition();

Which is const the getPosition or the Vector3? Not from a C++ point of view, but a more generic one. Which one is const?

That is only a problem if the position of the const is not unique If the rule is to put const after the type or function name, there is no ambiguity. I mean, that was the whole point, wasn't it? If you remove the const from Ogre::Vector3 from your example, you arrive at the exact same code.

[Kojack]

After many years of C++ programming, it's very inconsistent to me. I don't think there should be any whitespace between the * and type. Because the * indicates the type. I would go as far as saying, unless it's in a list it should be syntax error to have it any other way.

Breaking compatibility with the way C has done variable declaration for 38 years just because some C++ coders don't like a space on the left of an asterisk is a bit extreme. The whitespace has no meaning, so it shouldn't be an error to include it.


Having the space on the right of the asterisk is misrepresenting how variable declarations are actually handled by c++. Variable types like int are declaration specifiers. Variable names on their own or combined with pointers, references or arrays are declarators. A declaration is made of a series of specifers then a comma separated list of declarators. Although people hate the example of "int* a, b;" where a is a pointer and b isn't, and say they should be written as 2 statements, that's how the specifiers and declarators work. "*a" is a declarator, so the asterisk placed beside the variable name is a better representation of the syntax of declaration.

So... how do people write a const pointer to an int?

Code: Select all

int* const a;
int *const a;
int*const a;
int * const a;

The asterisk and the const are both part of the declarator and bind to the variable name, not the type specifier.

But asterisk spacing is really the most insignificant formatting issue in c++. Something like brace placement has a much bigger visual impact (but still no actual syntax impact).

[MrD]

When I have control over my own coding standards.

When declaring a variable I will do:

Code: Select all

int *var;
const int *var;
int *const var;
const int *const var;

However when declaring the return type of a function I will do:

Code: Select all

int* someFunc()  { ... }
const int* someFunc()  { ... }

I do it differently in the second case purely because I find the following looks weird:

Code: Select all

int *SomeClass::someFunc() { ... }

[Kojack]

That actually looks pretty good.

[JaJDoo]

i had this exact debate with someone a few days ago

i have about the same attitude as MrD to this

i used to always put the * in the type name side, since logically its where it should be;
that said, i found that putting it on the other side screams better "im a pointer". since class/type names length (string-wise) can differ dramatically, it makes it easier to quickly identify pointers where i declare them in a block (mainly because i always tab the names to the same 'column')

in this way, you need to 'actively' read each of the types and look for the * to find out which one is a pointer.

Code: Select all

LongClassNameBlarg*	view;
ShortCName*		     t_bar;
int				       index;

in this way, it easily stand out on its own (at least, to my eyes)

Code: Select all

LongClassNameBlarg	*view;
ShortCName		     *t_bar;
int				       index;

that said, when declaring pointers in code (not just declarations) i do usually emphasize the logic this way (am i contradicting myself..?):

Code: Select all

    Ogre::Root*         r       =   createNewRoot();
    Ogre::RenderSystem* rsys    =   r->getRenderSystemByName( qName.toStdString() );

however, in method/function return type, the opposite seems to be easier on the eyes, as MrD wrote.
of course its a matter of milliseconds, but it makes quickly assessing code easier for me.
for instance, code examples from trolltech exert much more brain power to overview, since its all "bunched" to my eyes.

in general, i try and make my code as easy to overview as possible; even methods arguments in calls, variable declarations or if statements of related lines of code i usually tab like:

Code: Select all

    rangeSpinBox->setValue          ( d->dat->attenuation_params[0] );
    constantDoubleSpinBox->setValue ( d->dat->attenuation_params[1] );
    linearDoubleSpinBox->setValue   ( d->dat->attenuation_params[2] );
    quadraticDoubleSpinBox->setValue( d->dat->attenuation_params[3] );
...

    setItemWidget(i, 1, typesComboBox           );
    setItemWidget(i, 2, editDiffuseColorButton  );
    setItemWidget(i, 3, editSpecularColorButton );
    setItemWidget(i, 4, editParamsButton        );
...

    QMap<QString, QComboBox*> pairs         = localLaunchDialog->getPairs(qName);
    QMap<QString, QComboBox*>::iterator it  = pairs.begin();
...

    if(localLaunchDialog)   delete localLaunchDialog;
    if(localGridDialog)     delete localGridDialog;
    if(log_dock)            delete log_dock;
...

dunno about you, but it just makes it easier for my brain to take it all in faster..

[lingfors]

Pointer * variable;

[CABAListic]

Pointer * variable;

Just couldn't decide, eh?

[toglia]

@JaJDoo That's a pretty tabbed code there. For sure might be faster to read, but looks harder to maintain.

[nikki]

@JaJDoo That's a pretty tabbed code there. For sure might be faster to read, but looks harder to maintain.

No text is hard to maintain if you use a real editor like vim.

[betajaen]

vim.

You misspelled sublime there Nikki.

[nikki]

vim.

You misspelled sublime there Nikki.

Bah, (g)vim has had those features for years. Except for the 'minimap' - but that's what taglist is for (at least you can see the text). And with python/vimscript and text-piping through perl or whatever you can do anything.

It has regular expressions though. Cool.

[jacmoe]

Pointer * variable;

If anyone cares, I'm with JajDoo. All the way.

It just feels right to write it like this:

Code: Select all

int* pointerToInt;

But, that really depends...

I see that the Qt Trolls are using type *pointer, so when I write Qt code I must admit that I sometimes cave in and uses that notation..

It's a matter of taste/convention.

Like camelCase versus Pascal naming conventions for functions:
camelCasedFuntion
PascalFunction