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

Discussion in 'C++' started by Sal, May 29, 2008.

  1. Sal

    Sal Guest

    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.
     
    Sal, May 29, 2008
    #1
    1. Advertising

  2. Sal

    Christopher Guest

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

    On May 29, 5:20 pm, Sal <> wrote:
    > 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.
     
    Christopher, May 29, 2008
    #2
    1. Advertising

  3. Sal wrote:

    > 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
     
    Chris Gordon-Smith, May 30, 2008
    #3
  4. Chris Gordon-Smith wrote:
    > 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.
     
    Juha Nieminen, May 30, 2008
    #4
  5. Juha Nieminen wrote:

    > 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.
     
    Matthias Buelow, May 30, 2008
    #5
  6. On 2008-05-30 09:22, Juha Nieminen wrote:
    > Chris Gordon-Smith wrote:
    >> 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;


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

    --
    Erik Wikström
     
    Erik Wikström, May 30, 2008
    #6
  7. Erik Wikström <> writes:

    > On 2008-05-30 09:22, Juha Nieminen wrote:
    >> Chris Gordon-Smith wrote:
    >>> 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;

    >
    > 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.

    --
    __Pascal Bourguignon__
     
    Pascal J. Bourguignon, May 30, 2008
    #7
  8. Sal

    peter koch Guest

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

    On 30 Maj, 17:18, Matthias Buelow <> wrote:
    > Juha Nieminen wrote:
    > > 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.


    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
     
    peter koch, May 30, 2008
    #8
  9. Sal

    Andrew Kerr Guest

    Pascal J. Bourguignon wrote:
    > Erik Wikström <> writes:
    >> On 2008-05-30 09:22, Juha Nieminen wrote:
    >>> int* p1, p2;

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


    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.

    --
    Andrew Kerr
     
    Andrew Kerr, May 30, 2008
    #9
  10. Sal wrote:

    > 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?
     
    Paul Brettschneider, May 30, 2008
    #10
  11. Sal

    James Kanze Guest

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

    On May 30, 8:44 pm, peter koch <> wrote:
    > On 30 Maj, 17:18, Matthias Buelow <> wrote:


    > > Juha Nieminen wrote:
    > > > 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.


    > 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 (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, May 31, 2008
    #11
  12. Sal

    James Kanze Guest

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

    On May 30, 6:02 pm, (Pascal J. Bourguignon)
    wrote:
    > Erik Wikström <> writes:
    > > On 2008-05-30 09:22, Juha Nieminen wrote:
    > >> Chris Gordon-Smith wrote:
    > >>> 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;


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


    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.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, May 31, 2008
    #12
  13. Sal

    peter koch Guest

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

    On 31 Maj, 11:02, James Kanze <> wrote:
    > On May 30, 8:44 pm, peter koch <> wrote:
    >
    > > On 30 Maj, 17:18, Matthias Buelow <> wrote:
    > > > Juha Nieminen wrote:
    > > > > 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.

    > > 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.


    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 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.


    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
     
    peter koch, May 31, 2008
    #13
  14. Re: Here we go again: int *n or int* n

    On May 29, 11:20 pm, Sal <> wrote:
    > 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.
     
    Tomás Ó hÉilidhe, May 31, 2008
    #14
  15. Sal

    James Kanze Guest

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

    On May 31, 12:13 pm, peter koch <> wrote:
    > On 31 Maj, 11:02, James Kanze <> wrote:
    > > On May 30, 8:44 pm, peter koch <> wrote:


    > > > On 30 Maj, 17:18, Matthias Buelow <> wrote:
    > > > > Juha Nieminen wrote:
    > > > > > 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.
    > > > 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.


    > 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.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jun 1, 2008
    #15
  16. Chris Gordon-Smith wrote:
    > Sal wrote:
    >
    >> 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


    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
     
    Joshua Brinsfield, Jun 2, 2008
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. amit
    Replies:
    0
    Views:
    394
  2. che
    Replies:
    2
    Views:
    500
  3. Schnoffos
    Replies:
    2
    Views:
    1,220
    Martien Verbruggen
    Jun 27, 2003
  4. Hal Styli
    Replies:
    14
    Views:
    1,646
    Old Wolf
    Jan 20, 2004
  5. abcd

    Importing again and again

    abcd, Jun 8, 2006, in forum: Python
    Replies:
    9
    Views:
    330
    Maric Michaud
    Jun 9, 2006
Loading...

Share This Page