Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!mucs!liv-cs!markr
From: markr@and.cs.liv.ac.uk
Newsgroups: comp.lang.c++
Subject: Re: Help needed in c++
Message-ID: <1991Jun22.162513.183@and.cs.liv.ac.uk>
Date: 22 Jun 91 16:25:13 GMT
References: <3257@odin.cs.hw.ac.uk> <1991Jun19.141917.18345@auto-trol.com>
Organization: Computer Science, Liverpool University
Lines: 56


mattel@auto-trol.com (Matt Telles) writes:
> marina@cs.hw.ac.uk (Marina Georgiadou) writes:
> >
> > Does anybody know the meaning of this const postfix ??
> 
> The const postfix notation indicates that the method (f) does NOT modify the
> object for which it is messaged (this).
> 
> What do other people think of using this notation?  Is it useful?
> 

I have one small gripe about the const postfix.

I have a smart pointer class.  Each pointer has an ID number for the object
it "points" to; when the smart pointer is dereferenced the first time it will
load the object from a database, or locate it via an object table.  The address
of the object is stored in a member of the smart pointer so that access is as
quick as possible next time:-

class Smart {
	int ident;
	Object* address;
public:
	Object* operator->() {
		if( ! address ) {
			address = find_or_load_object( ident );
		}
		return address;
	}
	// etc.
};

The thing is, I would like to have "const" smart pointers for which the
identifier cannot be changed -- like an "Object *const".  But if I declare
operator->() as a const member function, it cannot assign to "address".
If operator->() is not const postfixed, it cannot be called for a const smart
pointer, making the latter just a bit useless.

What I am trying to say is, I would prefer the const postfix to mean that the
programmer doesn't mind that function being called on a const object, rather
than meaning that no members may be changed by that function.  This would
seem to me to make more sense since the notion of a constant object is not as
simple as the notion of a constant integer or float.  An object is, after all,
an abstraction over finer-grained data inside, so shouldn't the notion of what
makes an object constant/nonconstant also be abstracted?

Protecting the bit pattern of a const object's allocated space is IMHO
over-protective.  A programmer should be able to use "const Car" to mean that
the colour cannot change or the engine cannot be removed, without preventing
the lights being switched on or the tank being filled :-)

My 2p's worth.

Mark Rivers
CompSci, Liverpool Uni, UK.