>>>>> "A" == Anil Kumar Vijendran <akv@marsh.cacs.usl.edu> writes:
>>>>> On 01 Oct 1995 05:39:01 GMT, vandevod@cs.rpi.edu (David
A> Vandevoorde) said:
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.
[...]
David> Wouldn't this cause problems when attempting to delete
David> const pointers?

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

A> I don't understand how "delete xp" would be true. Because delete takes
A> a void * and how can a X* const be converted to void* const? Is that a
A> standard conversion by any chance? I'd be surprised if it is.

Note that 8.3.5/3 says:
 " [about cv-qualifiers for parameter types...] Such cv-qualifiers
   affect only the definition of the parameter within the body of
   the function. [...]"
and 13.1/3 further confirms that `operator delete(void*, size_t);' is
equivalent to `operator delete(void* const, size_t);'.

I think (not sure) that this would make `delete xp;' above legal. (After
all, parameter passing in C++ is ``by value'' by default.)

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

akv@marsh.cacs.usl.edu (Anil Kumar Vijendran) writes:

>>>>>> vandevod@cs.rpi.edu (David Vandevoorde) said:
>    David>  X* const xp = new X; // ...  delete xp; // Or is this
>    David> illegal anyway? I suspect not.
>
>I don't understand how "delete xp" would be true. Because delete takes
>a void * and how can a X* const be converted to void* const? Is that a
>standard conversion by any chance? I'd be surprised if it is.

There appears to be some confusion here between `X * const' and `const X *'.
Conversion from a `X * const' to a `void * const' is perfectly OK,
just as conversion from `X *' to `void *' is; the top-level consts
are irrelevant in this case.

The code

 X* const xp = new X;
 // ...
 delete xp;

is certainly quite legal, and as far as I known always has been - all
compilers ought to accept it.

However, consider a closely related example:

 const X* xp = new X;
 // ...
 delete xp;

According to the ARM, this code was illegal - it was an error to delete
a pointer to const.  However, the ARM never spelt out whether or not
`new const X' was legal.  At the November 94 meeting in Valley Forge,
Pa., the C++ committee decided to allow `new const X'; having decided
to allow this, it was pretty much a requirement to allow deletion of a
pointer to const, otherwise there would be no convenient way to delete
objects allocated with `new const X'.  So that example is also legal,
although some compilers may not yet allow it.

In that example, even though the operand of the delete operator is
a pointer of type `const X *', the pointer that is passed to the
`operator delete' function is of type `void *', not `const void *'
or `const X *'.  The reason is because write protection only lasts
from when the constructor returns until the destructor is called.
The `this' pointer that is passed to the destructor has type `X *',
not `const X *'.  Once the destructor has finished executing, the
pointer points only to raw memory, and so has type `void *'.

An object proceeds through a variety of stages during its lifetime,
and the pointer to the object has a different type at each stage:

 stage    type
 -----    ----
 memory allocated  void *

 constructor entered  X *

 constructor completes,
 write protection enabled const X *

 write protection disabled, X *
 destructor entered

 destructor completes,  void *
 memory deallocated

These conversions between the different types are done implicitly by
the compiler.

--
Fergus Henderson             |  "Australia is the richest country in the world,
fjh@cs.mu.oz.au              |   according to a new system of measuring wealth
http://www.cs.mu.oz.au/~fjh  |   announced by the World Bank yesterday."
PGP: finger fjh@128.250.37.3 |  - Melbourne newspaper "The Age", 18 Sept 1995.

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

fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>However, consider a closely related example:
>
> const X* xp = new X;
> // ...
> delete xp;
>
>According to the ARM, this code was illegal - it was an error to delete
>a pointer to const.  However, the ARM never spelt out whether or not
>`new const X' was legal.  At the November 94 meeting in Valley Forge,
>Pa., the C++ committee decided to allow `new const X'; having decided
>to allow this, it was pretty much a requirement to allow deletion of a
>pointer to const, otherwise there would be no convenient way to delete
>objects allocated with `new const X'.  So that example is also legal,
>although some compilers may not yet allow it.

IMHO, this decision was a serious mistake, as before the decision, a
program that did not cast away const could not alter an object that it
only had a const pointer or reference to; now it can.  It can hardly
be argued that deleting an object does not modify it.

How many programmers would expect that the body of the function

void some_func(const char *);

might be

void some_func(const char * foo) { delete [] foo;}

I would hope that compilers at least emit warnings about this practice,
regardless of what mistake the committee might have made.

--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Anagrams for "information superhighway": Enormous hairy pig with fan
      A rough whimper of insanity
---
[ 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 <44k3iv$mok@cnn.Princeton.EDU>
           tim@franck.Princeton.EDU "Tim Hollebeek" writes:

 > Ronald F. Guilmette <rfg@monkeys.com> wrote:
 > >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.

I also agree....dare I suggest the preprocessor option...

#define self (*this)

(P.S. I apologise to those concerned if the above quotes are misattributed)
Regards,
 Andy
--
* Andy Sawyer ** e-mail:andys@thone.demon.co.uk ** Compu$erve:100432,1713 **
 The opinions expressed above are my own, but you are granted the right to
 use and freely distribute them. I accept no responsibility for any injury,
 harm or damage arising from their use.                --   The Management.
---
[ 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. ]

jbuck@Synopsys.COM (Joe Buck) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>>However, consider a closely related example:
>>
>> const X* xp = new X;
>> // ...
>> delete xp;
>>
>>According to the ARM, this code was illegal - it was an error to delete
>>a pointer to const.  However, the ARM never spelt out whether or not
>>`new const X' was legal.  At the November 94 meeting in Valley Forge,
>>Pa., the C++ committee decided to allow `new const X'; having decided
>>to allow this, it was pretty much a requirement to allow deletion of a
>>pointer to const, otherwise there would be no convenient way to delete
>>objects allocated with `new const X'.  So that example is also legal,
>>although some compilers may not yet allow it.
>
>IMHO, this decision was a serious mistake, as before the decision, a
>program that did not cast away const could not alter an object that it
>only had a const pointer or reference to; now it can.  It can hardly
>be argued that deleting an object does not modify it.

That's not correct.  Even before the decision at Valley Forge, it
was legal for a function to destroy a const object.  For example,
following code was always allowed (well, at least since Cfront 2.x):

 void foo(const T *p) {
  p->~T();
 }

So the guarantee that you are arguing should have been preserved
never existed in the first place.

--
Fergus Henderson             |  "Australia is the richest country in the world,
fjh@cs.mu.oz.au              |   according to a new system of measuring wealth
http://www.cs.mu.oz.au/~fjh  |   announced by the World Bank yesterday."
PGP: finger fjh@128.250.37.3 |  - Melbourne newspaper "The Age", 18 Sept 1995.

[ 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 6023@thone.demon.co.uk, Andy Sawyer <andys@thone.demon.co.uk> writes:
>In article <44k3iv$mok@cnn.Princeton.EDU>
>           tim@franck.Princeton.EDU "Tim Hollebeek" writes:

> > Ronald F. Guilmette <rfg@monkeys.com> wrote:
> > >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.

>I also agree....

The reason "this" is a pointer is that it was introduced into C++ before
references were part of the language. If references had been part of C++
at the time, "this" would have been a reference. (I believe you can find
that comment in D&E.)

I hope everyone realizes that it is far too late now to change "this" to
a reference. The change would break every C++ program in exchange for a
very minor notational convenience. (You don't normally need to write "this"
very often in a program, but nearly every program contains a few instances.)

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

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

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

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

Steve Clamage (clamage@Eng.Sun.COM) wrote:
: In article 95Sep1110410@physics12.Berkeley.EDU, tblancha@evolving.com (Todd Blanchard) writes:
: >This is common in C:
: >
: >#define free(X) { free(X); X=0; }
: >
: >You could do something similar in C++ as:
: >
: >void operator delete (void*& p, size_t s)
: >{
: >   ::delete p;
: >   p = 0;
: >}
: >
: >but the standard definition is:
: >void operator delete(void* p, size_t);
: >
: >Why is that?

: 1. The argument to operator delete need not be an lvalue:
:  T* foo();
:  ...
:  delete foo();

Possibly, but zeroing a ref to temp is still harmless.

: 2.  Believing that this approach solves the dangling pointer problem even
: in C, is naive, and leads to a false sense of security. The program might
: have any number of copies of the pointer which was deleted, and the copies
: would still dangle. You have to use a design discipline that keeps track of
: who owns the heap object and under what circumstances it is to be deleted.

This is plain insulting.  I know how to manage memory.  I continue to look
for techniques to reduce the consequences of screw-ups.

I never said it solved the dangling pointer problem.  It can help mitigate
it though.  Half a life jacket is better than no life jacket at all.  Idiotic
unix hackers that call any attempt to reduce the consequences of brain lock
"naive" and insist on leaving everything as dangerous as possible so people will
retain that heightened sense of awareness one gets living in a war zone are
clearly the naive ones.

Designers could try telling the truth once in awhile and say something like:
"Nobody thought of it early enough and its too late to change now."
Which I suspect is more likely.

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

In article lvf@citadel.evolving.com, tblancha@evolving.com (Todd Blanchard) writes:
>
>Designers could try telling the truth once in awhile and say something like:
>"Nobody thought of it early enough and its too late to change now."
>Which I suspect is more likely.

Except in this case, the approach had been discussed years ago and rejected
as not a good idea. See D&E, for example.

I recommend that you do a minimum of research before accusing others
of laziness and mendacity.

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

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

This is common in C:

#define free(X) { free(X); X=0; }

You could do something similar in C++ as:

void operator delete (void*& p, size_t s)
{
   ::delete p;
   p = 0;
}

but the standard definition is:
void operator delete(void* p, size_t);

Why is that?
--
-----------------------------------------------------------------------
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. ]

In article 95Sep1110410@physics12.Berkeley.EDU, tblancha@evolving.com (Todd Blanchard) writes:
>This is common in C:
>
>#define free(X) { free(X); X=0; }
>
>You could do something similar in C++ as:
>
>void operator delete (void*& p, size_t s)
>{
>   ::delete p;
>   p = 0;
>}
>
>but the standard definition is:
>void operator delete(void* p, size_t);
>
>Why is that?

1. The argument to operator delete need not be an lvalue:
 T* foo();
 ...
 delete foo();

2.  Believing that this approach solves the dangling pointer problem even
in C, is naive, and leads to a false sense of security. The program might
have any number of copies of the pointer which was deleted, and the copies
would still dangle. You have to use a design discipline that keeps track of
who owns the heap object and under what circumstances it is to be deleted.

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