🚀 go-pugleaf

Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
: 
<snip>
: |   3.8  Object Lifetime                                      [basic.life]
: | 5 A  program  may  end the lifetime of any object by reusing the storage
: |   which the object occupies or by explicitly calling the destructor  for
: |   an  object  of  a  class  type  with a non-trivial destructor.
: [...]
: | 6 After the lifetime of an object has ended and while the storage  which
: |   the  object  occupied still exists, any pointer to the original object
: |   can be used but only in limited ways.  Such a pointer still points  to
: |   valid  storage and using the pointer as a pointer to the storage where
: |   the object was located, as if the pointer were of type void*, is well-
: |   defined.   However,  using the pointer to refer to the original object
: |   is no longer valid.  In particular, such a pointer cannot be  derefer-
: |   enced; ...
<snip>

This seems to conflict with two (mis)impressions that I had about
pointers to deleted objects:

  1) If the expression denoting the object in a delete expression is
     a modifiable lvalue, its value is undefined after the deletion.
     (ARM p.63)

  2) The result of merely reading (not dereferencing) a pointer object
     holding an invalid value (e.g. the address of a deleted object)
     is defined to be undefined.
     
I understood from a thread three or four months ago (possible in
comp.lang.c++) that (2) came about as a result of the need to allow
pointers to be stored in special registers whose hardware did a
validity check on every access, a point which seems related to the 
strange 486 behavior mentioned by John Skaller in the current thread.

Tom Payne (thp@cs.ucr.edu)

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]