Quantcast

convention for declaring pointers?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

convention for declaring pointers?

Rik-4
jwe,

Is there a convention for whether to cuddle the '*' for pointers with the
variable name, variable type, or neither?  I noticed in
liboctave/array/idx-vector.h declarations such as the following

idx_range_rep * r = dynamic_cast<idx_range_rep *> (rep);

I started to change this to

idx_range_rep *r = ...

but then I realized that maybe the extra space is good.  It is consistent
with the rest of Octave coding conventions which tends to emphasize extra
whitespace for readability.  The space between the name of a function and
the opening parenthesis is an example of this openness.

--Rik

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: convention for declaring pointers?

Mike Miller-4
On Sun, Apr 23, 2017 at 22:15:27 -0700, Rik wrote:

> jwe,
>
> Is there a convention for whether to cuddle the '*' for pointers with the
> variable name, variable type, or neither?  I noticed in
> liboctave/array/idx-vector.h declarations such as the following
>
> idx_range_rep * r = dynamic_cast<idx_range_rep *> (rep);
>
> I started to change this to
>
> idx_range_rep *r = ...
>
> but then I realized that maybe the extra space is good.  It is consistent
> with the rest of Octave coding conventions which tends to emphasize extra
> whitespace for readability.  The space between the name of a function and
> the opening parenthesis is an example of this openness.

I've always seen the style

    idx_range_rep *r = ...

preferred, and I think we pretty consistently prefer that in Octave so
far. It also helps emphasize that the '*' is required for each
declaration in a compound declaration like

    octave_idx_type *ridx, *cidx;

GNU indent also corrects the string "int * x" to "int *x".

--
mike

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: convention for declaring pointers?

Rik-4
On 04/23/2017 10:40 PM, Mike Miller wrote:

> On Sun, Apr 23, 2017 at 22:15:27 -0700, Rik wrote:
>> jwe,
>>
>> Is there a convention for whether to cuddle the '*' for pointers with the
>> variable name, variable type, or neither?  I noticed in
>> liboctave/array/idx-vector.h declarations such as the following
>>
>> idx_range_rep * r = dynamic_cast<idx_range_rep *> (rep);
>>
>> I started to change this to
>>
>> idx_range_rep *r = ...
>>
>> but then I realized that maybe the extra space is good.  It is consistent
>> with the rest of Octave coding conventions which tends to emphasize extra
>> whitespace for readability.  The space between the name of a function and
>> the opening parenthesis is an example of this openness.
> I've always seen the style
>
>     idx_range_rep *r = ...
>
> preferred, and I think we pretty consistently prefer that in Octave so
> far. It also helps emphasize that the '*' is required for each
> declaration in a compound declaration like
>
>     octave_idx_type *ridx, *cidx;
>
> GNU indent also corrects the string "int * x" to "int *x".

This is usually the style I have seen as well.  What got me thinking about
the alternative construction was the analogy to nouns and adjectives in the
English language.

The declaration

int var;

is made of of a type (int, or noun) and a name (var).  Now, if you add
modifiers they are generally associated with the noun rather than the
name.  This works in C++ too as the type can have several modifiers.

unsigned int var;
unsigned short int var;

Finally, if something is a pointer one would say in English something like
"var is a pointer to unsigned int".  If one could, the natural coding would be

* unsigned int var;

But, that's not legal syntax so the question was whether having all the
adjectives separated

unsigned int * var;

might be clearer than

unsigned int *var

Of course, names are proper nouns in English and can also be modified by
adjectives, for example, "the treacherous Lady Macbeth".

I don't have a dog in this race and am happy to use either.

--Rik


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: convention for declaring pointers?

Rik-4
In reply to this post by Mike Miller-4
On 04/24/2017 08:32 AM, Rik wrote:
> On 04/23/2017 10:40 PM, Mike Miller wrote: >> On Sun, Apr 23, 2017 at 22:15:27 -0700, Rik wrote: >>> jwe, >>> >>> Is there a convention for whether to cuddle the '*' for pointers with the >>> variable name, variable type, or neither?  I noticed in >>> liboctave/array/idx-vector.h declarations such as the following >>> >>> idx_range_rep * r = dynamic_cast<idx_range_rep *> (rep); >>> >>> I started to change this to >>> >>> idx_range_rep *r = ... >>> >>> but then I realized that maybe the extra space is good.  It is consistent >>> with the rest of Octave coding conventions which tends to emphasize extra >>> whitespace for readability.  The space between the name of a function and >>> the opening parenthesis is an example of this openness. >> I've always seen the style >> >>     idx_range_rep *r = ... >> >> preferred, and I think we pretty consistently prefer that in Octave so >> far. It also helps emphasize that the '*' is required for each >> declaration in a compound declaration like >> >>     octave_idx_type *ridx, *cidx; >> >> GNU indent also corrects the string "int * x" to "int *x". > > This is usually the style I have seen as well.  What got me thinking about > the alternative construction was the analogy to nouns and adjectives in the > English language. > > The declaration > > int var; > > is made of of a type (int, or noun) and a name (var).  Now, if you add > modifiers they are generally associated with the noun rather than the > name.  This works in C++ too as the type can have several modifiers. > > unsigned int var; > unsigned short int var; > > Finally, if something is a pointer one would say in English something like > "var is a pointer to unsigned int".  If one could, the natural coding would be > > * unsigned int var; > > But, that's not legal syntax so the question was whether having all the > adjectives separated > > unsigned int * var; > > might be clearer than > > unsigned int *var > > Of course, names are proper nouns in English and can also be modified by > adjectives, for example, "the treacherous Lady Macbeth". > > I don't have a dog in this race and am happy to use either.

Just for fun, I looked at the Cplusplus.com tutorial and they code it with the space.

int * number;
char * character;
float * greatnumber;

And I looked at the C++11 FAQ on Stroustrup's own website and his examples use the other convention

class Arena {
  void* p;
  int s;
public:
  Arena(void* pp, int ss);

Obviously, we should do whatever we want.

--Rik
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: convention for declaring pointers?

Rik-4
In reply to this post by Mike Miller-4
On 04/24/2017 08:32 AM, Rik wrote:
> On 04/23/2017 10:40 PM, Mike Miller wrote: >> On Sun, Apr 23, 2017 at 22:15:27 -0700, Rik wrote: >>> jwe, >>> >>> Is there a convention for whether to cuddle the '*' for pointers with the >>> variable name, variable type, or neither?  I noticed in >>> liboctave/array/idx-vector.h declarations such as the following >>> >>> idx_range_rep * r = dynamic_cast<idx_range_rep *> (rep); >>> >>> I started to change this to >>> >>> idx_range_rep *r = ... >>> >>> but then I realized that maybe the extra space is good.  It is consistent >>> with the rest of Octave coding conventions which tends to emphasize extra >>> whitespace for readability.  The space between the name of a function and >>> the opening parenthesis is an example of this openness. >> I've always seen the style >> >>     idx_range_rep *r = ... >> >> preferred, and I think we pretty consistently prefer that in Octave so >> far. It also helps emphasize that the '*' is required for each >> declaration in a compound declaration like >> >>     octave_idx_type *ridx, *cidx; >> >> GNU indent also corrects the string "int * x" to "int *x". > > This is usually the style I have seen as well.  What got me thinking about > the alternative construction was the analogy to nouns and adjectives in the > English language. > > The declaration > > int var; > > is made of of a type (int, or noun) and a name (var).  Now, if you add > modifiers they are generally associated with the noun rather than the > name.  This works in C++ too as the type can have several modifiers. > > unsigned int var; > unsigned short int var; > > Finally, if something is a pointer one would say in English something like > "var is a pointer to unsigned int".  If one could, the natural coding would be > > * unsigned int var; > > But, that's not legal syntax so the question was whether having all the > adjectives separated > > unsigned int * var; > > might be clearer than > > unsigned int *var > > Of course, names are proper nouns in English and can also be modified by > adjectives, for example, "the treacherous Lady Macbeth". > > I don't have a dog in this race and am happy to use either.

Just for fun, I looked at the Cplusplus.com tutorial and they code it with the space.

int * number;
char * character;
float * greatnumber;

And I looked at the C++11 FAQ on Stroustrup's own website and his examples use the other convention

class Arena {
  void* p;
  int s;
public:
  Arena(void* pp, int ss);

Obviously, we should do whatever we want.

--Rik
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: convention for declaring pointers?

Daniel Sebald
On 04/24/2017 10:47 AM, Rik wrote:

> On 04/24/2017 08:32 AM, Rik wrote:
>> On 04/23/2017 10:40 PM, Mike Miller wrote: >> On Sun, Apr 23, 2017 at 22:15:27 -0700, Rik wrote: >>> jwe, >>> >>>
> Is there a convention for whether to cuddle the '*' for pointers with
> the >>> variable name, variable type, or neither?  I noticed in >>>
> liboctave/array/idx-vector.h declarations such as the following >>> >>>
> idx_range_rep * r = dynamic_cast<idx_range_rep *> (rep); >>> >>> I
> started to change this to >>> >>> idx_range_rep *r = ... >>> >>> but
> then I realized that maybe the extra space is good.  It is consistent
>>>> with the rest of Octave coding conventions which tends to emphasize
> extra >>> whitespace for readability.  The space between the name of a
> function and >>> the opening parenthesis is an example of this openness.
>>> I've always seen the style >> >>     idx_range_rep *r = ... >> >>
> preferred, and I think we pretty consistently prefer that in Octave so
>>> far. It also helps emphasize that the '*' is required for each >>
> declaration in a compound declaration like >> >>     octave_idx_type
> *ridx, *cidx; >> >> GNU indent also corrects the string "int * x" to
> "int *x". > > This is usually the style I have seen as well.  What got
> me thinking about > the alternative construction was the analogy to
> nouns and adjectives in the > English language. > > The declaration > >
> int var; > > is made of of a type (int, or noun) and a name (var).  Now,
> if you add > modifiers they are generally associated with the noun
> rather than the > name.  This works in C++ too as the type can have
> several modifiers. > > unsigned int var; > unsigned short int var; > >
> Finally, if something is a pointer one would say in English something
> like > "var is a pointer to unsigned int".  If one could, the natural
> coding would be > > * unsigned int var; > > But, that's not legal syntax
> so the question was whether having all the > adjectives separated > >
> unsigned int * var; > > might be clearer than > > unsigned int *var > >
> Of course, names are proper nouns in English and can also be modified by
>> adjectives, for example, "the treacherous Lady Macbeth". > > I don't
> have a dog in this race and am happy to use either.
>
> Just for fun, I looked at the Cplusplus.com tutorial and they code it
> with the space.
>
> int * number;
> char * character;
> float * greatnumber;
>
> And I looked at the C++11 FAQ on Stroustrup's own website and his
> examples use the other convention
>
> class Arena {
>   void* p;
>   int s;
> public:
>   Arena(void* pp, int ss);
>
> Obviously, we should do whatever we want.
>
> --Rik

Stroustrup was probably thinking along the lines you were, that the
pointer modification should be grouped with the other qualifiers, but
that isn't the best when it comes to treating a string of qualifiers as
one unit, e.g., <unsigned long int*> just doesn't look natural.  I would
guess, though, he made a conscious decision to not use this format:

   float * greatnumber

because at quick glance, to me that looks like multiplication.  And
quick glance is important when it comes to searching through code.  And
what to do with pointer to pointer?

   float * * greatnumberpointer

?

It's sort of making the best of a situation with no good solution, but
I've come to prefer

   float *greatnumber

Dan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: convention for declaring pointers?

John W. Eaton
Administrator
In reply to this post by Mike Miller-4
On 04/24/2017 01:40 AM, Mike Miller wrote:

> On Sun, Apr 23, 2017 at 22:15:27 -0700, Rik wrote:
>> jwe,
>>
>> Is there a convention for whether to cuddle the '*' for pointers with the
>> variable name, variable type, or neither?  I noticed in
>> liboctave/array/idx-vector.h declarations such as the following
>>
>> idx_range_rep * r = dynamic_cast<idx_range_rep *> (rep);
>>
>> I started to change this to
>>
>> idx_range_rep *r = ...
>>
>> but then I realized that maybe the extra space is good.  It is consistent
>> with the rest of Octave coding conventions which tends to emphasize extra
>> whitespace for readability.  The space between the name of a function and
>> the opening parenthesis is an example of this openness.
>
> I've always seen the style
>
>     idx_range_rep *r = ...
>
> preferred, and I think we pretty consistently prefer that in Octave so
> far. It also helps emphasize that the '*' is required for each
> declaration in a compound declaration like
>
>     octave_idx_type *ridx, *cidx;
>
> GNU indent also corrects the string "int * x" to "int *x".

Yeah, I've always used "int *x", probably from reading the first edition
of K&R, which notes that "*x" is an int.

For references, however, I've always written "int& y", which is what I
first saw in the first edition of TC++PL.

There is also this:  http://www.stroustrup.com/bs_faq2.html#whitespace

Currently, I think we mostly use "int *x" and "int& y" and would be
happy to continue doing that.  If you feel strongly that we should use
consistent spacing for pointers and references, then I'd prefer

   "int* x" and "int& y"

over

   "int *x" and "int &y".

And I'd definitely prefer any of the above over using spaces on both
sides of the "*" and "&".

jwe


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: convention for declaring pointers?

Rik-4
On 04/24/2017 12:55 PM, John W. Eaton wrote:

> On 04/24/2017 01:40 AM, Mike Miller wrote:
>> On Sun, Apr 23, 2017 at 22:15:27 -0700, Rik wrote:
>>> jwe,
>>>
>>> Is there a convention for whether to cuddle the '*' for pointers with the
>>> variable name, variable type, or neither?  I noticed in
>>> liboctave/array/idx-vector.h declarations such as the following
>>>
>>> idx_range_rep * r = dynamic_cast<idx_range_rep *> (rep);
>>>
>>> I started to change this to
>>>
>>> idx_range_rep *r = ...
>>>
>>> but then I realized that maybe the extra space is good.  It is consistent
>>> with the rest of Octave coding conventions which tends to emphasize extra
>>> whitespace for readability.  The space between the name of a function and
>>> the opening parenthesis is an example of this openness.
>>
>> I've always seen the style
>>
>>     idx_range_rep *r = ...
>>
>> preferred, and I think we pretty consistently prefer that in Octave so
>> far. It also helps emphasize that the '*' is required for each
>> declaration in a compound declaration like
>>
>>     octave_idx_type *ridx, *cidx;
>>
>> GNU indent also corrects the string "int * x" to "int *x".
>
> Yeah, I've always used "int *x", probably from reading the first edition
> of K&R, which notes that "*x" is an int.
>
> For references, however, I've always written "int& y", which is what I
> first saw in the first edition of TC++PL.
>
> There is also this:  http://www.stroustrup.com/bs_faq2.html#whitespace
>
> Currently, I think we mostly use "int *x" and "int& y" and would be happy
> to continue doing that.  If you feel strongly that we should use
> consistent spacing for pointers and references, then I'd prefer
>
>   "int* x" and "int& y"
>
> over
>
>   "int *x" and "int &y".
>
> And I'd definitely prefer any of the above over using spaces on both
> sides of the "*" and "&".

We can do whatever we like.  I made a note of our convention for pointers
and references at http://wiki.octave.org/C%2B%2B_style_guide.  And I fixed
up all the pointer instances in Octave to reflect the convention "int *x"
in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/e35a5c1233d0).  I
used grep, but apparently there were no occurrences of 'int & y'.

--Rik

Loading...