🚀 go-pugleaf

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

> I don't know what your ARM is (the red/gold ANSI draft standard?), but
> you are right of course.

The Annotated C++ Reference Manual, by Margaret A. Ellis and Bjarne
Stroustrup.  This is the ANSI base document, and the closest thing to a C++
standard available now.

> (I wonder how you can quote that fast)

Good index.

>>   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 a 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.

No one will argue that C++ is one of the "truer" OOPLs... In this
particular instance, the at method is supposed to return an Object*&.  If
there isn't one at the index specified, what do you return?  The NIHCL
decided to return the nil object.  Unfortunately, nil isn't of type
Object*&, so it needed to be cast to the correct type.  This is not with
the intention of modifying nil (a singularly bad idea, I agree), but
allowing functions of this nature to return a consistent value.  There is
no way to return a const object from a non-const method except by casting
it to a non-const object.  libg++ just doesn't make the nil objects const.
If you have a better solution, I'd be interested to hear it...

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

True, but I still think g++ ought to implement the C++ standard as it
stands...

--
Jason Merrill
jason@jarthur.claremont.edu