From: Gerhard Menzl on
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
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
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

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
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! ]