🚀 go-pugleaf

clamage@Eng.Sun.COM (Steve Clamage) writes:
	...
>1. You can call operator delete with something which cannot be modified.

Couldn't this be accomodated by a normal overload between signatures
of (void *v&,size_t) and (const void *&,size_t)?

>2. Even if you set the pointer to null after a delete, you may
>still have other copies of the pointer in the program. If delete

Sure, it would _not_ be a fix for design problems, such as not
clarifying which of those several pointers is the "owning" one;
it would just add a little explicit language support for the
rather common style in which the object with the owning-pointer
"remembers" having already done the deletion by nulling it.

>did the nulling automatically, it would provide a false sense of
>security that you didn't have to worry about dangling pointers
>when in fact you do need to worry about them. If you use a

This seems inconsistent with other aspects of the language,
where providing some (incomplete) assistance was deemed
preferable to providing none at all.

>programming discipline that ensures pointers don't dangle, you
>then don't need to set the pointers to null. If you still want

Sure, e.g. if all allocations are constructors of objects which
just encapsulate the owning-pointer, and all deletions only
done in the destructors of those objects.  But isn't it part of
the philosophical underpinning of C++ not to force a single
style/discipline down programmers' throats?

>to set them to null anyway, you can. For example, use a function
>to do the deleting, and set the pointer to null in that function.

True; simple templates should do it, e.g. something like:

template <class T> inline void release(T *&p) { delete p; p=0; }
template <class T> inline void release_array(T *&p) { delete[] p; p=0; }

I accept this single reason as sufficient -- "the language already
offers convenient ways to support the required style" looks to me
like a perfectly acceptable reason to avoid changing the language.
My objections are just against the other, "supporting" reasons
offered.


Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it                            Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: +39 (51) 597120

[ 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. ]