🚀 go-pugleaf

>>>>> On Fri, 10 Apr 92 10:05:08 +0200, Ulrich Windl <c9524@rrzc1.rz.uni-regensburg.de> said:

The code in question:

-----
...
	static Object* const nil;  // pointer to sole instance of nil object
...
Object*& Arraychar::at(int)
{
	shouldNotImplement("at");
	return (Object*&)nil;		
}
...
-----

>>   Arraychar.c:291: conversion to reference of read-only variable `nil'

>>   Here g++ should quietly cast away nil's const-ness.

> I think it should NOT, because there's a good reason:
> If you tell the compiler that a variable (nil) is to be const.
> In most cases it is an error if you cast away const-ness.

I disagree.  If you are deliberately casting it, that is sufficient
indication that you want its status to change.  In any case, this is an
issue that should be taken up in comp.lang.c++, not here; the current C++
standard states that (Object*&)nil returns nil cast to a non-const
pointer reference.  I refer you to the ARM, section 5.4:

"An object of a const type or a reference to an object of a const type can
be cast into a reference to a non-const type.  The resulting reference will
refer to the original object.  The result of attempting to modify that
object through such a pointer or reference will either cause an addressing
exception or be the same as if the original pointer or reference had
referred a non-const object.  It is implementation dependent whether the
addressing exception occurs."

So g++ has the option of protecting nil from being written to, but it
cannot prevent the programmer from casting it into a non-const reference
and still maintain compatibility with the ARM standard.

> Furthermore it make the code optimizer less efficient.
> Maybe the compiler should warn, but what's a constant, if you can change it?

That's a philosophical issue which is not really relevant to this
discussion.

--
Jason Merrill
jason@jarthur.claremont.edu