Here we go again: int *n or int* n

[Sal]

I'm aware of all the religious arguments of the former over the
latter, but does anyone know why Bjarne Stroustrup seems to prefer
int* n ? Dumb question, but I just had to ask.

 

[Christopher]

I'm aware of all the religious arguments of the former over the
latter, but does anyone know why Bjarne Stroustrup seems to prefer
int* n ? Dumb question, but I just had to ask.

Personally I prefer
int * n to denote a pointer to an integer.
int & n to denote a reference to an integer.
&n to denote the address of n.
*n to denote dereferencing of a pointer named n.

 

[Chris Gordon-Smith]

I'm aware of all the religious arguments of the former over the
latter, but does anyone know why Bjarne Stroustrup seems to prefer
int* n ? Dumb question, but I just had to ask.

I don't know BS's reasoning, but I read "int* n" as "n is an integer
pointer".

"int *n" seems to say "If you dereference n, you get to an integer".

The former seems more intuitive to me.

That being said, Item 0 of Sutter and Alexandrescu's "C++ Coding Standards"
says "Don't Sweat the Small Stuff". In other words, don't worry too much
about thingsa that really are just a matter of taste.

Chris Gordon-Smith
www.simsoup.info

 

[Juha Nieminen]

I don't know BS's reasoning, but I read "int* n" as "n is an integer
pointer".

"int *n" seems to say "If you dereference n, you get to an integer".

The former seems more intuitive to me.

It may be more intuitive (and is what I use as well, for that reason),
but thinking about it like that causes an embarrassing problem:

int* p1, p2;

With that thinking you'd also think that you are creating two
int-pointers above, when in fact you are not (you are creating an
int-pointer named p1 and an int variable named p2).

Correcting that while still keeping the intuition is not easy. What I
personally usually do is to just avoid the problem and use two lines:

int* p1;
int* p2;

It's more verbose, though.

 

[Matthias Buelow]

int* p1;
int* p2;
It's more verbose, though.

One could typedef int *int_ptr; and then use that. The question is, why
isn't that used (more often)? Seems the *-quirk is elegant enough for
daily use and doesn't cause many problems.

 

[Erik Wikström]

It may be more intuitive (and is what I use as well, for that reason),
but thinking about it like that causes an embarrassing problem:

int* p1, p2;

What I find embarrassing is the fact that p2 is not a pointer, what kind
of logic is that.

 

[Pascal J. Bourguignon]

What I find embarrassing is the fact that p2 is not a pointer, what kind
of logic is that.

Yes, that's why you should neve declare more than one variable at once in C/C++.

int* p1;
int* p2;

Or better, choose another programming language. Are we all
implementing kernel level programs? I doubt it.

 

[peter koch]

One could typedef int *int_ptr; and then use that. The question is, why
isn't that used (more often)? Seems the *-quirk is elegant enough for
daily use and doesn't cause many problems.

I believe that one variable per declaration is a good idea. The
verbosity you add is not worth bothering about. I never met a
programmer that could program as ifast as he could type, so there is
no bottleneck here ;-)
The problem with your pointer-definition is the loss of flexibility.
You would now need another typedef for at pointer to const int and so
would end up with tow definitions for every pointer. Also, the int_ptr
is in my opinion less readable: at least, this convention will take a
little while getting used to.

/Peter

 

[Andrew Kerr]

the logic of the language designers.

If you write

int *p1, p2;

the meaning is clear. This is why fluency in the language is critical if
you are going to use it for anything significant. If you have difficulty
distinguishing between variable declaration and dereference operators,
you're going to have a great deal of trouble getting things to work.
This is not meant to flame, that's just how it is.

Yes, that's why you should neve declare more than one variable at once in C/C++.

a.) See above.
b.) One can make the argument that you should never repeat yourself. If
a set of variables *must* be the same type for code to make sense [i.e.
assignments and such between them], then one should declare them with
the same type identifier. For example,

float *matrixA,
*matrixB,
*matrixC;

is preferable to

float *matrixA;
float *matrixB;
float *matrixC;

and is helpful when you want to change the type to, say, double.
Clearly, using C++ reduces the need to maintain pointers of things [you
could have a matrix class of sorts: matrix<float> A, B, C; ].

The bottom line is when intuition yields results that are incompatible
with reality, you must move beyond what your intuition offers.

Or better, choose another programming language. Are we all
implementing kernel level programs? I doubt it.

C++ is quite powerful, especially when combined with a decent set of
libraries [like Boost]. One need never write C code unless a C++
compiler for the target architecture doesn't exist.

 

[Paul Brettschneider]

I'm aware of all the religious arguments of the former over the
latter, but does anyone know why Bjarne Stroustrup seems to prefer
int* n ? Dumb question, but I just had to ask.

It's an unpopular opinion, but for me "int* n" looks like denial. Maybe it
would be nice if the * would bind to the int and you could write
  int* p1, p2;  // two pointers to int
but, like it or not, C++ does not work that way. I prefer the notation that
reflects reality (int *p1, *p2 (or int &p1, &p2)).

You wouldn't write "a+b * c" either, would you?

 

[James Kanze]

One could typedef int *int_ptr; and then use that. The
question is, why isn't that used (more often)? Seems the
*-quirk is elegant enough for daily use and doesn't cause
many problems.

[/QUOTE]

I believe that one variable per declaration is a good idea.
The verbosity you add is not worth bothering about. I never
met a programmer that could program as ifast as he could type,
so there is no bottleneck here ;-)

I have, but that's because they were slow typers, and poor
programmers (who didn't think things out first). Realistically,
however, C++ does contain a lot of boiler plate, so while you
will spend more time thinking about what you should write than
actually writing it, once you've thought about it and know what
is needed, typing can be a bottleneck to getting it down on
disk. A programmer who can't touch type is missing an important
productivity tool.

The problem with your pointer-definition is the loss of
flexibility.

The problem with the typedef for a pointer is the loss of
readability. The purpose of a typedef is abstraction; normally,
you don't want to abstract out the fact that you're dealling
with a pointer, since anyone using the type must be aware of it.
(A typedef to a pointer is valid if you expect the pointer to be
used as an opaque handle; in other words, if the client code
should not count on it being a pointer.)

 

[James Kanze]

The same logic which makes you put part of the type information
after the name, e.g. "int a[10]" (rather than "array [10] of
int").

Yes, that's why you should neve declare more than one variable
at once in C/C++.

int* p1;
int* p2;

That's a good rule in general, in any language.

Or better, choose another programming language.

But which one. C++ has a lot of problems (especially with
declaration syntax), and is really a horrible language when it
comes down to it. But all of the others I've seen are even
worse.

 

[peter koch]

I have, but that's because they were slow typers, and poor
programmers (who didn't think things out first).  Realistically,
however, C++ does contain a lot of boiler plate, so while you
will spend more time thinking about what you should write than
actually writing it, once you've thought about it and know what
is needed, typing can be a bottleneck to getting it down on
disk.  A programmer who can't touch type is missing an important
productivity tool.

This is funny, because I remember having used some editors that did
contain macros for generating the boilerplate code. So pressing CTRL-I
created an if statement, CTRL-F a function - placing the cursor at the
"correct" place - e.g. after the "(" for the if-statement. I never
found it worthwhile to learn those shortcuts and I'm a rather poor
typist.
For the problem with two similar declarations, I write the first
declarations, copy it and change the name of the variable (and
probably the initialisation) in the second declaration.

The problem with the typedef for a pointer is the loss of
readability.  The purpose of a typedef is abstraction; normally,
you don't want to abstract out the fact that you're dealling
with a pointer, since anyone using the type must be aware of it.

I mentioned that in the part you snipped away. The reason I did not
emphasize it so much is because it really does not take that long to
get used to the convention that appending _pointer (or _const_pointer)
to a name declares a pointer to the type of the first part of the
name. That it requires a little bending to call it an abstraction is
not a problem for me. typedefs are used for different stuff than
abstractions anyway.

/Peter

 

[Tomás Ó hÉilidhe]

I'm aware of all the religious arguments of the former over the
latter, but does anyone know why Bjarne Stroustrup seems to prefer
int* n ? Dumb question, but I just had to ask.

I use:

int *p;

because it accurately reflects the grammar of both C and C++.

A normal declaration looks something like as follows:

Type name;

or:

Type name1, name2, name3;

The complication to this simple scheme, however, is that you can have
pointers and references. If you want to make a pointer out of
something, you add the asterisk to its _name_, not to its type. Same
goes for arrays, you add the [N] to the name, not the type. That's why
we have declarations such as:

int (*pFunc)(int,int);

I suggest strongly against taking the asterisk and putting it with the
typename:

int* p;

because it goes against the grammar.

 

[James Kanze]

This is funny, because I remember having used some editors
that did contain macros for generating the boilerplate code.

Some of the boiler plate is usually generated automatically by
the editor. I've never worked on a system where the editor
didn't automatically generate the copyright, and the include
guards for a .h, for example, and it's pretty frequent for them
to automatically generate the basic structure of a class
declaration. On the other hand, I've never seen one that would
automatically generate all of the forwarding constructors. Nor,
for that matter, which would generate empty function bodies for
the function implementations (in another file), given the class
definition.

So pressing CTRL-I created an if statement, CTRL-F a function
- placing the cursor at the "correct" place - e.g. after the
"(" for the if-statement. I never found it worthwhile to learn
those shortcuts and I'm a rather poor typist.

I've never found those worthwhile either. A macro that, when
the cursor is placed on a function in a header file, would
create a new file with an empty definition for the function
would be useful, however.

For the problem with two similar declarations, I write the
first declarations, copy it and change the name of the
variable (and probably the initialisation) in the second
declaration.

Copy/paste can help a lot, I agree.

 

[Joshua Brinsfield]

I don't know BS's reasoning, but I read "int* n" as "n is an integer
pointer".

"int *n" seems to say "If you dereference n, you get to an integer".

The former seems more intuitive to me.

That being said, Item 0 of Sutter and Alexandrescu's "C++ Coding Standards"
says "Don't Sweat the Small Stuff". In other words, don't worry too much
about thingsa that really are just a matter of taste.

Chris Gordon-Smith
www.simsoup.info

The intuition-wise justification for the other ("int *n;") is arrived at
by thinking of * only as a dereference operator: then you have "int
(*n);", which should declare the value of n dereferenced as an
int--which would implicitly declare n as a pointer to int. And since
there's no typename like "pointer<int>" we can use, then we don't have
any way to do pointer declarations explicitly; and so it would make
sense to do it implicitly through the dereference operator.

Then it makes sense and your intuitive revulsion can lie dormant,
enjoying a full belly of intellectual kluge .

-Brinsfield