Am 26.09.00, 02:38:48, schrieb David R Tribble <david@tribble.com> zum
Thema Re: NULL "this" pointers:


> Andrei Alexandrescu wrote:
> >> The thing with delete nullifying its argument is that it promises
> >> more that it can actually do...

> David R Tribble wrote:
> >> Such as?  "Delete the object pointed to by a pointer, then invalidate
> >> the pointer."  What more should it do?

Why should a language primitive do multiple things in this way. If I need
an object deleted, I say 'delete', if I need a visibly invalid pointer, I
set it to null.
(BTW: If the dtor throws, should the pointer still be nullified ?)

> James Kuyper wrote:
> > Zero all of the pointers to the same piece of memory. Which it can't
> > do.  Which it must do, to justify the sense of safety that some people
> > mistakenly derive from it.

> How is this any different than the ("false") sense of safety derived
> by the programmer setting a just-deleted pointer to null explicitly?

If the language itself ensures that a pointer is not left dangling after
a delete, that suggests that the language should do this to all pointers
(which it doesn't) and that checking for null pointers actually means
checking for a valid object.

If I wish to reuse a pointer after deleting the object pointed to, I have
to manually nullify it (unless I reassign it immediately, in which case I
don't want to pay for a nullification). If I have to do that even if that
pointer is the only pointer to this object, and if I get used to doing it
in that case when it is needed, then I can't be mistaken that, if there
were multiple pointers to that object, it has to be done for each one.

IMHO the nullification also should be done only where appropriate. If the
pointer in question outlives the current context, if it therefore can
(and will) be reused and if its semantics allow it to be null, then I may
and should to set it to null after deleting the object pointed to.
(Whether or not the object is deleted through this modifiable lvalue).

> You've described the situation of having several pointers point to
> the same object and then deleting that object.  Surely that's a
> problem for the programmer who wrote the code, and not a problem for
> the compiler.  It he's going to have multiple pointers laying around,
> then he should take the responsibility of keeping track of all of
> them, and subsequently nullifying them when the shared object is
> deleted.  The compiler can't, and shouldn't, assume more than one
> object pointer per delete.

If has going to have even a single pointer staying around and being
accessed after the delete, then he should take the responsibility of
keeping track of it, and subsequently nullifying it when the object is
deleted.

If the pointer desn't stay around, why should anyone nullify it.

> ======================================= MODERATOR'S COMMENT:
>  Warning:  The Standard-related content in this thread branch is
flatlining...

I didn't feel crossposting and migrating this thread to a different group
was justified. In a way we are still dicussing what the C++ language does
and should or shouldn't do. Discussing common (or not so common) idioms
and usage must surely be part of that.

But to please the charta let's spell that out:

The language should provide constructs that embody coherent concepts or
support certain techniques in a coherent way. The Standard (there you
relate) should not be changed by adding patches for little pitfalls, if
those changes blur concepts that are orthogonal by other means.

The C++ language (this is inherited from C) does not ensure that non-null
pointers point to valid objects only.

Adding language support for automatically synchronizing object and
pointer invalidation in any context, does indeed imply that the language
supports this conceptually.

It therefore would promise something this programming language cannot do

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]