Reference to void
in [C++]
|
From: Gerhard Menzl on 2 Nov 2006 06:17 Frederick Gotham wrote: > When you say that something is a "reference to const" or a "pointer to > const", you're saying that the pointer cannot be used to alter the > target object. You're _not_saying that the target option is const. Er, yes, this is exactly the point I was trying to make, and which Greg Herlihy disputes. -- Gerhard Menzl Non-spammers may respond to my email address, which is composed of my full name, separated by a dot, followed by at, followed by "fwz", followed by a dot, followed by "aero". [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Gerhard Menzl on 2 Nov 2006 06:18 Greg Herlihy wrote: > When bound to the 2, ref is a "reference to const", when bound to ci, > it is a "reference to a non-const". So on every call to f(), ref is > consistently claiming that its bound object is const - even though we > know that at least on some of the calls, that claim is false. So > rather than buy wholeheartedly into ref's claims, we should stick to > what we know and attribute the "const" to its source - the declaration > of ref itself. So f()'s ref paramter is a "const reference" and we > leave the question of the object's actual const-ness unspecified > (unless it can be determined for certain). Once again: this is about the terms we use to talk about static types. It is about what you call ref in a declaration like void f(int const& ref); In most cases, there is no way to tell whether the object a reference is bound to is actually const or not. It is also irrelevant; as soon as you access an object through a reference, the available operations you can perform on it are determined by the type of the reference, not the type of the object - unless you cast away constness. > We should do so because there is one thing that we can be sure of: is > that there is another, direct declaration for the ref's object > somewhere else in the program - a declaration that really determines > the constness of object. And ref's own declaration does not affect the > declaration for the actual object. So we should reserve "reference to > const" when we know that the referenced object is const, and use > "const reference" as the shorthand for "a reference to a (supposedly) > const object". I don't see what this would buy you. What is the use of expressing that the "supposedly const object" is not that const after all, when all you have is a reference that limits your access to the const interface? > Whether ref's object is actually declared const or not is far from a > meaningless distinction. On the contrary, it directly affects whether > it is safe to cache ref's value or not. And the distinction exists - > whether or not we choose to acknowledge it or nor, or even whether we > can determine it in a particular case. The choice is between a richer > vocabulary that is capable of expressing the difference, rather than a > watered-down terminology that cannot. Whether an object can safely be cached is part of the higher level contract, it simply cannot be expressed in the C++ type system. Therefore it is misleading to pretend it can. > Pointers use indirection, references use aliasing. A pointer does not > claim to be the object that it points to. A pointer to an int is not > an int. A reference on the other hand makes exactly that claim: a > reference to an int is an int. A reference to a const int is a const > int. Whereas a const reference to an int is only an int object > pretending (under an assumed name) to be const. It should be possible > to express in words all three types of references. What is the practical use if distinguishing between the latter two types? When I have an int const&, all that is relevant is that I am not allowed to modify the object being referred. Constness matters primarily at compile-time; throwing aspects that cannot be resolved at this stage into the terminology is what I would call watering down. -- Gerhard Menzl Non-spammers may respond to my email address, which is composed of my full name, separated by a dot, followed by at, followed by "fwz", followed by a dot, followed by "aero". [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Frederick Gotham on 2 Nov 2006 06:13 Greg Herlihy: > When bound to the 2, ref is a "reference to const", when bound to ci, > it is a "reference to a non-const". Nope. Here's a "pointer to const": int const *p; It remains a pointer to const whether it points to a const object or not: int a; int const b; p = &a; p = &b; Why is everyone so confused by this?!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > So on every call to f(), ref is > consistently claiming that its bound object is const No. If a reference is "to const", or if a pointer is "to const", then that pointer or reference shall not be used to alter the object in question. I can give you 532 trillion examples of where a "pointer to const" points to a non-const object, or where a "reference to const" refers to a non-const object -- but they are STILL a "pointer to const" and a "reference to const". The "restrict" specifier, on the other hand, implies that the object shall not be changed within the lifetime of the pointer or reference. int const *restrict p = ...; int const &restrict r = ...; > Pointers use indirection, references use aliasing. A pointer does not > claim to be the object that it points to. A pointer to an int is not an > int. Stick an asterisk before it and it is. > A reference on the other hand makes exactly that claim: a > reference to an int is an int. A reference to a const int is a const > int. It behaves as a const int, yes. -- Frederick Gotham [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: ThosRTanner on 2 Nov 2006 06:30 James Kanze wrote: > Francis Glassborow wrote: > > In article <1162047140.568184.80310(a)b28g2000cwb.googlegroups.com>, James > > Kanze <james.kanze(a)gmail.com> writes > > > >Yes, but for better or worse, this misnomer has established > > >itself. In a similar way, people usually speak of T const* > > >as a const pointer, although it is the pointed to that is > > >const, and not the pointer. It's probably regrettable, but > > >the usage is too well established to change. > > > No, no, no. The use of const reference is relatively harmless > > because there is no real possibility of confusion in C++ where > > a reference is not reseatable. However the issue with pointers > > is completely different; a const pointer, a pointer to const > > and a const pointer to const are different things and must not > > be confused as all exist. > > I agree in theory, but I think realistically, the battle has > been lost. It was lost when the language allowed 'const int fred' as a synonym for 'int const fred'. You'd be surprised at the number of people who look at me strangely when I write 'int const *fred' rather than 'const int *fred', and then look very confused when I explain about a pointer to a const int and a const pointer to an int, and a const pointer to a const int and point out that my way of writing is more consistent when taken over the whole range of possibilities. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 2 Nov 2006 06:33
Gennaro Prota wrote: > On 1 Nov 2006 11:30:06 -0500, James Kanze wrote: > >> So a conforming compiler should treat it as an error? Then its > >> probably a bug with VC 2005 because the following lines: > >> int j = 23; > >> int& const i = j; > >> produce: > >> warning C4227: anachronism used : qualifiers on reference are ignored > >Which is fine if they document this as a diagnostic. [...] > >(FWIW: Sun has used the "anachronism" message for years.) > Does this mean that it was legal to cv-qualify a reference at some > point in the C++ history? :-O Maybe. For some compilers. I can't remember ever having tried it, and at any rate, I've not used every compiler which ever existed, so I can't say. -- James Kanze (GABI Software) email:james.kanze(a)gmail.com 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 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |