🚀 go-pugleaf

   From: jason@jarthur.Claremont.EDU
   References: <1992Apr3.092315.28243@muddcs.claremont.edu>
	   <9204100805.AA16361@rrzc1.rz.uni-regensburg.de>
   Date: Fri, 10 Apr 92 01:22:40 PDT

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

>
>   >>   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++
I was talking about a specific implementation, not about C++ in general.
>   standard states that (Object*&)nil returns nil cast to a non-const
>   pointer reference.  I refer you to the ARM, section 5.4:
I don't know what your ARM is (the red/gold ANSI draft standard?), but
you are right of course.
>
>   "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."
(I wonder how you can quote that fast)
>
>   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.
Procedural abstraction I'd call it. Is OOP worth anything if you must look
inside every procedure (sorry, method) to find out whether the constants you
pass are still the same afterwards.
You'll probably want to tell me that side-effects should be documented, but
if so, why don't you pass o copy of it.
And if the method receiving a pointer to a non-const object does not modify it
why aren't you using a const ?
Besides that the ANSI draft I know tells a lot about C++ but almost nothing
about goals of OOP. I recomment reading Bertrand Meyers's book about OOP and
Eiffel. 

That's not philosophical; that's the material your programs are built from.

----------------------------------------
Ulrich Windl
Universitaet Regensburg
Rechenzentrum
D-W8400 Regensburg
---
X.400: windl@vax1.informatik.fh-regensburg.dbp.de   (VAX/VMS soon invalid)
(Maybe you'll have to leave out ".dbp")
SMTP:  c9524@rrzc1.rz.uni-regensburg.de	            (Sun, my favorite)
SMTP:  uw@ngate.rzi.uni-regensburg.de		    (PC, Pegasus Mail)