Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #67047
| 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> |
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
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