🚀 go-pugleaf

Don Organ (dorgan@megatest.com) wrote:

: > Steve Clamage (stephen.clamage@eng.sun.com) wrote:
: > 
: > Except in this case, the approach had been discussed years ago and rejected
: > as not a good idea. See D&E, for example.

Todd Replies:  Its not there.  Got a page#?

: > 
: > I recommend that you do a minimum of research before accusing others
: > of laziness and mendacity.
: > 
: > ---
: > Steve Clamage, stephen.clamage@eng.sun.com

: I think the original question may have been slightly confusing.
: It showed
:      void operator delete (void*& p, size_t s)
: I think it was intended to be
:      void operator delete (void*& p)
: In D&E I found an answer to why the 2nd argument to delete is illegal.

Actually, as I did a minimum of research before posting this question,
you can find the full explanation of how to overload op delete on page
283 of the ARM which allows for both 

void operator delete(void*);
and
void operator delete(void*,size_t);

Meyers explains in item 10 ("Effective C++" for the unfamiliar) that the
second version is useful in the event of inheritance.  It allows you to
tell if you are being asked to delete the base class or some (larger) 
derived class.  If you didn't have a custom new for the derived class, and
you wrote the correct new in the base class, you need to check the size and
perform either the custom delete or the global delete depending on the size
of the object.

Nowhere can I find a rational explanation for why the pointer is not
passed as a void*& (to allow zeroing).  It would provide more 
flexibility in memory management schemes.

: What is the answer to the question:
:      why the 1st (only) argument must be void* and can't be void*&?
: From the original posting, the intention seems clear to allow the
: delete operator to assign 0 to the pointer passed as the
: argument (i.e. the pointer must be passed by reference, not by value).

: I did a minimum of research - but didn't find an answer in D&E.
: (And I've lost my ARM!)
: Could someone point me to the exact page in D&E (or ARM or anywhere)
: or post a rationale?

: Thanks.

: Don Organ

--
-----------------------------------------------------------------------
Todd Blanchard                                    tblancha@evolving.com
Evolving Systems Inc.                               VOX: (303) 689-1798
                                                    FAX: (303) 689-1399
"Never underestimate the power of stupid people in large groups."
-----------------------------------------------------------------------
---
[ 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. ]

tblancha@evolving.com (Todd Blanchard) writes:

>Don Organ (dorgan@megatest.com) wrote:

>: > Steve Clamage (stephen.clamage@eng.sun.com) wrote:
>: > 
>: > Except in this case, the approach had been discussed years ago and rejected
>: > as not a good idea. See D&E, for example.

>Todd Replies:  Its not there.  Got a page#?

I was certain that I had seen this in D&E or in the ARM, but the
discussion appears not to be in either place. The main reasons are
what I gave originally:

1. You can call operator delete with something which cannot be modified.
Page 63 of the ARM hints at this reason, but doesn't come out and say it.
	T* f();
	T* const p = new T;
	T& q = *(new T);
	...
	delete f();
	delete p;
	delete &q;
None of these delete expressions would be allowed if operator delete
took a void*&.

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
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
programming discipline that ensures pointers don't dangle, you
then don't need to set the pointers to null. If you still want
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.

I asked Bjarne Stroustrup if he had any other reasons in mind
and he confirmed that these were the reasons.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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. ]

tblancha@evolving.com (Todd Blanchard) writes:

>Don Organ (dorgan@megatest.com) wrote:

>: > Steve Clamage (stephen.clamage@eng.sun.com) wrote:
>: > 
>: > Except in this case, the approach had been discussed years ago and rejected
>: > as not a good idea. See D&E, for example.

>Todd Replies:  Its not there.  Got a page#?

I was certain that I had seen this in D&E or in the ARM, but the
discussion appears not to be in either place. The main reasons are
what I gave originally:

1. You can call operator delete with something which cannot be modified.
Page 63 of the ARM hints at this reason, but doesn't come out and say it.
	T* f();
	T* const p = new T;
	T& q = *(new T);
	...
	delete f();
	delete p;
	delete &q;
None of these delete expressions would be allowed if operator delete
took a void*&.

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
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
programming discipline that ensures pointers don't dangle, you
then don't need to set the pointers to null. If you still want
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.

I asked Bjarne Stroustrup if he had any other reasons in mind
and he confirmed that these were the reasons.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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. ]

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

In article <434me4$ov3@citadel.evolving.com>,
Todd Blanchard <tblancha@evolving.com> wrote:
>void operator delete(void*,size_t);
>...
>Nowhere can I find a rational explanation for why the pointer is not
>passed as a void*& (to allow zeroing).  It would provide more 
>flexibility in memory management schemes.

Maybe the answer is that delete came before references... then again,
maybe not.

Heck!  If you are going to ask about _that_ why not ask why member
functions get a `this' _pointer_ rather than a `this' reference?
The latter would clearly have been a far better choice.
-- 

-- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------
---- E-mail: rfg@monkeys.com ----------- Purveyors of Compiler Test Suites -
----------------------------------------------------------------------------


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

In article <44irni$10e@segfault.monkeys.com>,
Ronald F. Guilmette <rfg@monkeys.com> wrote:
>
>In article <434me4$ov3@citadel.evolving.com>,
>Todd Blanchard <tblancha@evolving.com> wrote:
>>void operator delete(void*,size_t);
>>...
>>Nowhere can I find a rational explanation for why the pointer is not
>>passed as a void*& (to allow zeroing).  It would provide more 
>>flexibility in memory management schemes.
>
>Maybe the answer is that delete came before references... then again,
>maybe not.

My guess would be that in the event of multiple pointers to the same
block, zeroing one pointer doesn't really solve anything.  If the
pointer were zeroed, people might get the impression that they don't
have to keep track of what has been freed.

>Heck!  If you are going to ask about _that_ why not ask why member
>functions get a `this' _pointer_ rather than a `this' reference?
>The latter would clearly have been a far better choice.

Agreed. I'm tired of returning *this.
-- 
Tim Hollebeek      | Everything above is a true statement, for sufficiently
PChem Grad Student | false values of true.
Princeton Univ.    | C++ == OOP--
-------------------| tim@handel.princeton.edu  http://wagner.princeton.edu/~tim

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

>>>>> "RG" == Ronald F Guilmette <rfg@monkeys.com> writes:
RG> In article <434me4$ov3@citadel.evolving.com>,
RG> Todd Blanchard <tblancha@evolving.com> wrote:
>> void operator delete(void*,size_t);
>> ...
>> Nowhere can I find a rational explanation for why the pointer is not
>> passed as a void*& (to allow zeroing).  It would provide more 
>> flexibility in memory management schemes.

RG> Maybe the answer is that delete came before references... then again,
RG> maybe not.

Wouldn't this cause problems when attempting to delete const pointers?

	X* const xp = new X;
	// ...
	delete xp; // Or is this illegal anyway? I suspect not.

	Daveed


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

Ronald F. Guilmette (rfg@monkeys.com) wrote:

|> In article <434me4$ov3@citadel.evolving.com>,
|> Todd Blanchard <tblancha@evolving.com> wrote:
|> >void operator delete(void*,size_t);
|> >...
|> >Nowhere can I find a rational explanation for why the pointer is not
|> >passed as a void*& (to allow zeroing).  It would provide more 
|> >flexibility in memory management schemes.

|> Maybe the answer is that delete came before references... then again,
|> maybe not.

I imagine that the real reason is that this would require an lvalue as
parameter for delete, and in general, this is *not* the case.  (Note
that the result of casting T* to a void* is *not* an lvalue.)

I'd be curious in hearing how to implement this proposal on machines
where void* does not have the same representation as T* (where T is a
class).
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

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