Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #67047

Re: how/why it is written ... int &numberRef; vs int& numberRef;

From Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups comp.lang.c++
Subject Re: how/why it is written ... int &numberRef; vs int& numberRef;
Date 2019-07-15 23:03 +0100
Organization A noiseless patient Spider
Message-ID <87muhf0xc1.fsf@bsb.me.uk> (permalink)
References <b51b5a56-3549-4e87-adb3-010bf0eadcf6@googlegroups.com> <qginun$233i$1@adenine.netfront.net>

Show all headers | View raw


Juha Nieminen <nospam@thanks.invalid> writes:

> G G <gdotone@gmail.com> wrote:
>> my question is why associate the *, or & the the type instead of the 
>> name? i do understand it is a preference.
>
> For some reason that I do not know (and possibly nobody does),
> when C was originally devised (although it might have come from a
> precursor language like B or BCPL, I don't know) they decided that
> the indicator for a pointer variable, ie. the asterisk, would be
> tied to the variable name rather than the type.

Neither B nor BCPL had types.  C was originally "B with types".

> In other words,
> the asterisk is not, in fact, part of the type at all, but a sort
> of indicator that "this variable is a pointer".
>
> This distinction can be seen, as some have pointed out, when declaring
> more than one variable in the same expression:
>
>   int *x, *y, z;
>
> Here x and y are pointers, while z is not. The asterisk, the indicator
> that means "this is a pointer", is tied to the variable name, not the
> type.
>
> Of course this can become a bit confusing when types are used in
> contexts other than variable declarations. While C-style typedefs
> kind of still follow this principle (as typedef syntax is essentially
> just normal variable declaration syntax with just the 'typedef' keyword
> added at the very beginning):
>
>   typedef int *IntPtr;
>
> it depends on your point of view whether this is now confusing or not:
>
>   IntPtr ptr;
>
> because now the "this is a pointer" part is part of the type alias,
> rather than tied to the variable name.
>
> When a function returns a pointer, it also can become a bit confusing,
> if you follow that same convention:
>
>   int *function();
>
> The "this is a pointer" asterisk kind of is part of the return type,
> kind of isn't. It's a bit confusing.

The general idea (now rather battered by history and changes to the
language) is that declarations mirror use.

  function

is a function designator.  To call it, you mirror the declaration:

  function()

The result is a pointer.  To dereference that pointer you again mirror
the declaration and use *:

  *function()

to get an int.

This idea of having declarations mirror use, gave rise to declarations
that have two parts: the base type (like int, double and so on) and what
C calls a declarator where operators like *, () and [] decorate the name
with the same priority as they appear in expressions.

Knowing both the history and syntax of declarations, I can't stand
seeing

  int* function();

but I know I am on the wrong side of history here, at least as far as
C++ is concerned.  I'm not going to defend it, but you wondered where
it came from.

> No wonder many prefer writing
> it like this for clarity:
>
>   int* function();
>
> which of course means the exact same thing, but is visually clearer.

This is the form that used to confuse me.  Not that I didn't understand
it, but I'd worry the author may not know how types work in C++.  Now
that is it almost de rigeur to write it this way, there's no reason to
worry -- the programmer is simply following standard advice -- it just
looks odd to me, like writing

  - a+b

where the spacing does not reflect the syntax.

> And yes, this is valid C (and C++):
>
>   int *function1(), *function2(), function3();
>
> even though it's quite rarely used. (I bet most C/C++ programmers
> weren't aware of that.)

Don't people learn the syntax of the languages they use anymore?  (I'm
joking, of course they don't, but C and C++ were designed in era when
they did.)

> C++ makes this even more complicated because there are many more
> situations where types are used on their own, without any sort of
> variable (or function) name, such as:
>
>   std::vector<int*> vec;
>
> Also here the asterisk kind of is part of the type, kind of isn't.
> It's all confusing.

-- 
Ben.

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

how/why it is written ... int &numberRef; vs  int& numberRef; G G <gdotone@gmail.com> - 2019-07-12 15:12 -0700
  Re: how/why it is written ... int &numberRef; vs int& numberRef; Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-07-12 23:16 +0100
    Re: how/why it is written ... int &numberRef; vs int& numberRef; G G <gdotone@gmail.com> - 2019-07-12 15:21 -0700
  Re: how/why it is written ... int &numberRef; vs int& numberRef; James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-07-12 18:55 -0400
  Re: how/why it is written ... int &numberRef; vs  int& numberRef; Öö Tiib <ootiib@hot.ee> - 2019-07-12 18:55 -0700
  Re: how/why it is written ... int &numberRef; vs int& numberRef; Szyk Cech <szykcech@spoko.pl> - 2019-07-13 05:33 +0200
  Re: how/why it is written ... int &numberRef; vs  int& numberRef; Juha Nieminen <nospam@thanks.invalid> - 2019-07-15 20:33 +0000
    Re: how/why it is written ... int &numberRef; vs  int& numberRef; Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-07-15 23:03 +0100
      Re: how/why it is written ... int &numberRef; vs  int& numberRef; Öö Tiib <ootiib@hot.ee> - 2019-07-15 18:31 -0700
        Re: how/why it is written ... int &numberRef; vs  int& numberRef; Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-07-16 03:04 +0100
          Re: how/why it is written ... int &numberRef; vs  int& numberRef; Öö Tiib <ootiib@hot.ee> - 2019-07-16 05:59 -0700
        Re: how/why it is written ... int &numberRef; vs int& numberRef; "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-16 05:48 +0200
          Re: how/why it is written ... int &numberRef; vs int& numberRef; David Brown <david.brown@hesbynett.no> - 2019-07-16 08:47 +0200
            Re: how/why it is written ... int &numberRef; vs int& numberRef; "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-16 11:52 +0200
              Re: how/why it is written ... int &numberRef; vs int& numberRef; David Brown <david.brown@hesbynett.no> - 2019-07-16 12:45 +0200
                Re: how/why it is written ... int &numberRef; vs int& numberRef; "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-17 07:06 +0200
                Re: how/why it is written ... int &numberRef; vs int& numberRef; David Brown <david.brown@hesbynett.no> - 2019-07-17 08:17 +0200
                Re: how/why it is written ... int &numberRef; vs int& numberRef; scott@slp53.sl.home (Scott Lurndal) - 2019-07-17 14:03 +0000
          Re: how/why it is written ... int &numberRef; vs int& numberRef; Öö Tiib <ootiib@hot.ee> - 2019-07-16 07:36 -0700
          Re: how/why it is written ... int &numberRef; vs int& numberRef; Juha Nieminen <nospam@thanks.invalid> - 2019-07-17 07:25 +0000
      Re: how/why it is written ... int &numberRef; vs  int& numberRef; Juha Nieminen <nospam@thanks.invalid> - 2019-07-17 07:24 +0000
        Re: how/why it is written ... int &numberRef; vs  int& numberRef; Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-07-17 12:53 +0100

csiph-web