In article <rtdm58751iv55@corp.supernews.com>, Gene Bushuyev <gbush@my-
Deja.com> writes
>"this" is not just a pointer, it is a special kind of pointer (think, for
>example, what metamorphoses it comes through in constructor). There are
>certain qualifications in 9.3.2p1 that are specified for this pointer that
>contradict operator delete. Neither it is said anywhere that "this" is a
>pointer created by a new-expression.

You will need to provide a very strong argument based on the actual text
of the standard (and not just a possible interpretation) that 'delete
this' is 'illegal' because I am certain that it was not the intention of
the standards committees that this should be the case.  (I actually
raised the issue and it was explained to me, informally, in considerable
detail why such a constraint would be very unwise.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <rtdb5pd11iv56@corp.supernews.com>,
  "Gene Bushuyev" <gbush@my-Deja.com> wrote:

> [snip]
> >Correct, but that doesn't mean the value of this has changed.  It
> >no longer has a referrant.

> I think we are trying to play a word game. Standard, certainly, isn't
> precise in this place and it may be the cause all these arguments. But
> we have to work with what we have, even if those who wrote it meant
> differently. If you follow the Occam's rule - the easiest and most
> direct explanation is a correct one, then what 9.3.2p1 says is this:
> when a member function is called, "this" is assigned a value equal to
> the address of the object,

No question here.

> and this value remains the same while in
> the body of that member function

That's not quite what it says, but close enough.  We are talking about
the value of this, though, and not the object.

> and it always contains the address of
> the same object.

No, it always contains the address of the object on which the function
was called.  There is not the slightest mention in 9.3.2 concerning the
state or the validity of the object.

There is not a shadow of a doubt that using this after the object is
deleted is undefined behavior.  Calling a non-static member function
(virtual or not) is also undefined behavior.  I can find no statement,
however, that says returning from a member function is undefined
behavior if the object is not valid.

If the object has ceased to exist, any expression resulting in the
address of the object is undefined behavior.  Given this, the compiler
can do whatever it wants with this after delete this -- there is no way
that a conforming program can tell.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <t7yaehb32h.fsf@calumny.jyacc.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:
> "Gene Bushuyev" <gbush@my-Deja.com> writes:
> > Yep, and the lifetime of "this" according to 9.3.2p1 is "the body of
> > a nonstatic member function"

> You know, even if your reading of the standard was correct, it
> wouldn't make one bit of difference. The "delete this" idiom is useful
> and used.  If it could be derived from the standard that such usage
> was illegal, then the standard would change, not the code, much in the
> same way that vector's storage is going to be made contiguous. If an
> implementation behaved in a way as to make "delete this" unsafe, the
> vendor would be changed, not the code. Get over it.

There's actually a slight difference in the two cases, at least as I
understand it.  I don't think that the issue of contiguous storage of a
vector was ever discussed in the committee; it was more or less
something that was either taken for granted or forgotten.  Whereas the
question of delete this was discussed several times -- each time with a
definite concensus that it must be legal.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <hI7d+BA94r13Ew5q@robinton.demon.co.uk>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:

> In article <fLuB3.36966$R84.648334@typ12.nn.bcandid.com>, Marco Dalla
> Gasperina <marcodg@panmed.com> writes
> >Are you saying that the implementation is allowed to change the
> >value of the pointer deleted?  I don't see how that could be given
> >that the argument to delete is an expression and not an lvalue.
> >There is also no wording in [5.3.5] expr.delete (that I can see)
> >which implies this.

> As I understand it, it is allowed to do absolutely anything it likes,
> and that certainly includes changing the value stored in a pointer (if
> it can find some way of locating the storage in order to make the
> change.  Of course it would be a very unusual compiler that managed to
> produce code that changed the value stored in the pointer used by
> delete.

But a very useful one:-).

It isn't actually very difficult to imagine a compiler which modified
the pointer passed to delete in the case where the expression was an
lvalue.  If it isn't implemented, it's probably largely because it
doesn't buy us anything -- what is needed is code to change *all* of the
pointers to the object, regardless of where they are, and that would
take a very special compiler.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <rtdm58751iv55@corp.supernews.com>,
  "Gene Bushuyev" <gbush@my-Deja.com> wrote:
>
> wmm@fastdial.net wrote in message <7r5ask$49h$1@nnrp1.deja.com>...
> [snip]
> >I think the answer _is_ clear from the Standard.  Agreed, there's
> >no place that the question of "delete this" is specifically
addressed.
> >However, it does say that "this" is a pointer (9.3.2p1), and it says
> >that you can use "delete" with a pointer to an object that was
> >created by a new-expression (5.3.5p1).
>
> "this" is not just a pointer, it is a special kind of pointer (think,
for
> example, what metamorphoses it comes through in constructor). There
are
> certain qualifications in 9.3.2p1 that are specified for this pointer
that
> contradict operator delete. Neither it is said anywhere that "this"
is a
> pointer created by a new-expression.

Taking the last point first, of course it is not said anywhere that
"this" is a pointer [to an object] created by a new-expression.  You
can have static and automatic objects, as well as objects created
by new-expressions.  It is invalid to use "delete" on a pointer to
a static or automatic object, whether the pointer's name is "this"
or anything else.  If the object was created by a new-expression,
however, then "this" for that object is (obviously) a pointer to
such an object, and such pointers can be used with "delete".

Regarding the "qualifications" in 9.3.2p1, this should be read as
specifying the interpretation of code in a member function and
nothing more.  What this says is that any use (explicit or implicit)
of the keyword "this" inside a member function is to be interpreted
as the address of the object for which the member function was
invoked.  If the status of that object changes -- it is destroyed
and/or its storage is freed, rendering its address invalid -- then
any use (explicit or implicit) of the keyword "this" that relies on
those properties will be an error resulting in undefined behavior.
If there is no such use, there is no problem.

As I recall your initial posting in this thread, you posited some
implementation-defined invisible operations using "this" at the end
of a member function, which would be rendered incorrect by "delete
this."  The Standard spells out what kinds of operations involve
the value of "this" in the abstract machine; if an implementation
adds extra operations, it's up to the implementation to ensure that
those operations are valid, just as it's up to the programmer to
ensure that his/her uses of "this" are valid.

One other thing: your interpretation of this paragraph would require
that the object lifetime persist until the end of the member function
("address of the object" presupposes both a valid address and a live
object).  Consider the example in 3.8p7, where an assignment operator
invokes the object's destructor and then uses placement "new" to
construct a copy of the other object in the storage -- _not_ an
object any more -- pointed to by "this".  This is a valid use of "this"
because it's only used as raw storage -- the placement argument --
during the time no object exists at that address.  Use of "this" in
other ways -- to invoke a member function, for instance -- after the
destructor call would produce undefined behavior.

The point I'm making is that the restrictions you cite from 9.3.2p1
apply only to _uses_ of "this".  If you don't use "this" in a way
that relies on those conditions, there is no problem.

--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <rtavfelq8os67@corp.supernews.com>,
  "Gene Bushuyev" <gbush@synopsys.com> wrote:
>
> Steve Clamage wrote in message <7r3kt8$pso$1@engnews1.eng.sun.com>...
> [snip]
> >I don't see anything in 9.3.2p1 that implies you cannot "delete
this".
> >It just says that "this" refers to the current object. If you delete
> >the object, "this" has no referent, the same as for any pointer
> >whose referent has been deleted.

> I'm afraid I'm repeating myself. Please tell me, is the value of
> "this" equal to "the address of the object for which the function is
> called" after "delete this"? Are we still "in the body of a nonstatic
> member function" after "delete this"? Whether it's intentional or not,
> this paragraph of the standard requires "this" to be a valid pointer
> to same valid object as at the moment the member function is called.

I quote the sentence in question: "In the body of a nonstatic member
function, the keyword this is a non-lvalue expression whose value is the
address of the object for which the function is called."  Where does it
say anything about that address remaining valid for the duration of the
function?  Or anything about the validity of the object for the duration
of the function.  The value of this is the address of the object FOR
WHICH THE FUNCTION WAS CALLED.  About the most one can conclude from
this is that there must be a valid object when the function is called.

More generally, have you really thought about the consequences of your
logic.  You talk about using a static function, but what is the
difference between "delete this", and
"static_fnc_which_deletes_arg(this)".  In both cases, after the
expression, you have a member function in which this is no longer valid,
because the object has ceased to exist.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient=E9e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James.Kanze@dresdner-bank.com wrote:
...
> lvalue.  If it isn't implemented, it's probably largely because it
> doesn't buy us anything -- what is needed is code to change *all* of the
> pointers to the object, regardless of where they are, and that would
> take a very special compiler.

Or an extra level of indirection in the implementation's definition of
what a C pointer is.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Gene Bushuyev" <gbush@my-Deja.com> writes:

>Lisa Lippincott wrote in message
><070919991656132177%lisa_lippincott@advisories.com>...
>[snip]
>>No, the compiler (like the programmer) must consider 3.8 [basic.life]
>>paragraph 3, "The properties ascribed to objects throughout this
>>International Standard apply for a given object only during its
>>lifetime."

>Yep, and the lifetime of "this" according to 9.3.2p1 is "the body of a
>nonstatic member function"

That has nothing whatever to do with the lifetime of the object to
which "this" points.

class T { void f(); };

void f()
{
    T* p = new T;
    delete p; // lifetime of *p ends
    T* q = p; // p still lives, but the operation is not valid
}

void T::f()
{
    delete this; // lifetime of *this ends
    T* q = this; // this still lives, but the operation is not valid
}

--
Steve Clamage, stephen.clamage@sun.com


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <fLuB3.36966$R84.648334@typ12.nn.bcandid.com>, "Marco Dalla
Gasperina" <marcodg@panmed.com> wrote:

> Are you saying that the implementation is allowed to change the
> value of the pointer deleted?  I don't see how that could be given
> that the argument to delete is an expression and not an lvalue.
> There is also no wording in [5.3.5] expr.delete (that I can see)
> which implies this.
>
> I can easily imagine an implementation munging the memory that was
> just deleted.  But I can't imagine one modifying the argument to
> delete.  Still, you seem pretty convinced; to the point of making
> me unsure of my previous assumptions.  Can you provide a reference
> please?



After "delete p", the bits in p may not have changed. But consider a
system with good memory protection: "delete p" can mark the memory that
was occupied by *p as "forbidden", and loading a pointer to "forbidden"
memory may cause your program to stop immediately.

So if you write quite innocently:

   if (p != NULL) {
      delete p;
      if (p == NULL)
         printf ("Whoops: I didnt know delete could change a pointer!\n");
   }

You would expect that this code is ok and cannot print anything. An
implementation could define that all pointers to deleted memory ARE null
pointers; quite possible with the right kind of hardware support. In that
case memcmp will not find p changed, but p == NULL is suddenly true. Or an
implementation could define that all pointers to deleted memory will crash
your program immediately; your program stops running as soon as it
compares p to NULL.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <rtauco368os86@corp.supernews.com>,
  "Michael VanLoon" <michaelv@edifecs.com> wrote:

    [Concerning delete this...]

> However, this isn't what I asked for.  I specifically asked for a
> definitive answer from the standard, and none has been given (although
> I appreciate all the effort put into finding an answer!)

I don't know exactly where to look in the standard, but the question was
raised in the committee, and at the time, there was a definite concensus
that it must be legal.  Unless this consensus changed at some later
time, the intent is clear: delete this is legal.  In practice, I think
it would be a rare program that didn't use it in some specific cases --
design decides who is responsible for the lifetime of an object, and for
certain types of objects, the logical owner is the object itself.  In
such cases, avoiding delete this (which is always possible) can only be
considered obfuscation.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

wmm@fastdial.net wrote in message <7r5ask$49h$1@nnrp1.deja.com>...
[snip]
>I think the answer _is_ clear from the Standard.  Agreed, there's
>no place that the question of "delete this" is specifically addressed.
>However, it does say that "this" is a pointer (9.3.2p1), and it says
>that you can use "delete" with a pointer to an object that was
>created by a new-expression (5.3.5p1).

"this" is not just a pointer, it is a special kind of pointer (think, for
example, what metamorphoses it comes through in constructor). There are
certain qualifications in 9.3.2p1 that are specified for this pointer that
contradict operator delete. Neither it is said anywhere that "this" is a
pointer created by a new-expression.

Gene Bushuyev




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <fLuB3.36966$R84.648334@typ12.nn.bcandid.com>, Marco Dalla
Gasperina <marcodg@panmed.com> writes
>Are you saying that the implementation is allowed to change the
>value of the pointer deleted?  I don't see how that could be given
>that the argument to delete is an expression and not an lvalue.
>There is also no wording in [5.3.5] expr.delete (that I can see)
>which implies this.

As I understand it, it is allowed to do absolutely anything it likes,
and that certainly includes changing the value stored in a pointer (if
it can find some way of locating the storage in order to make the
change.  Of course it would be a very unusual compiler that managed to
produce code that changed the value stored in the pointer used by
delete.

Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

blargg wrote:
>
> In article <07a4a4435040799CPIMSSMTPE01@msn.com>, "Gene Bushuyev"
> <gbush@my-deja.com> wrote:
>
> > Steve Clamage <clamage@eng.sun.com> wrote in message
> > news:7r0ls7$d07$1@engnews1.eng.sun.com...
> > [snip]
> > > Assuming that memory leaks are undesirable, alternatives to
> > > "delete this" would have been very complicated. I was quite
> > > surprised to see "delete this" fall out of the basic design.
> > > But it was easy to prove that it was appropriate and safe.
> >
> > Since I have already answered to the previous questions, I tackle only this
> > one.
> > 1) Firstly, I want to know, how can it be easy to prove that it is safe, if
> > according to the standard 9.3.2p1 it is not safe.
>
> I guess I missed the part that said "'delete this' is ill-formed".

Well, the question is *if* something like that is contained
indirectly (i.e. the standard obviously doesn't say
"you may not delete this", but doing it might result in
undefined behaviour anyway).

[...]

> > In the light of this, suicide is never a good practice. I'm
> > surprised to hear that it was ever an element of "basic design." Can you
> > address me to the literature where it is considered as a "basic design"
> > feature?
>
>     delete <pointer>
>
>     this = pointer to object member function was invoked on
>
>     put them together when appropriate

This analysis doesn't get the point:For int variables,

   variable = expression;

is valid, and

   ++variable

is a valid expression. Therefore from your reasoning,

   int i=0;
   i = ++i;

should be fine ("Put them together when appropriate")...

[...]
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <fLuB3.36966$R84.648334@typ12.nn.bcandid.com>,
  "Marco Dalla Gasperina" <marcodg@panmed.com> wrote:
>
>
> Gene Bushuyev <gbush@my-deja.com> wrote in message
> news:070672418040799CPIMSSMTPE01@msn.com...
> > Marco Dalla Gasperina <marcodg@pacifier.com> wrote in message
> > news:37d3f400.0@news.pacifier.com...
> > [snip]

> > > Even after 'delete this;' the keyword *this* still holds the
> > > address of the object on which the the member function was called.
> > > It just happens not to be valid anymore.

> > No, it doesn't. After "delete this" the value of "this" is
> > undefined.  It can be anything.

> Are you saying that the implementation is allowed to change the value
> of the pointer deleted?  I don't see how that could be given that the
> argument to delete is an expression and not an lvalue.  There is also
> no wording in [5.3.5] expr.delete (that I can see) which implies this.

I'm not sure what the final standard says, but historically, it has been
the case that after delete expr, if expr is an lvalue, its value is
undefined.  An implementation *could* set it to null, or any special
value, for example.  But only if the expression was an lvalue -- this is
not an lvalue (nor a variable), and so cannot be modified.

In fact, this is the key part.  This is a keyword, which evaluates to
the address of the object.  If there is no object (because of delete
this), then using this is undefined behavior.  But if you don't use
this, either explicitly or implicitly (because f() is actually the
equivalent of this->f()), there is no problem.

> > Moreover, since the object for which the member function was called
> > doesn't exist anymore, there is no way "this" can point to that
> > object. The wording of the standard absolutely precludes it.

This doesn't point to anything.  This doesn't exist, as an object.  This
is a keyword which evaluates to the address of the object.  If the
object doesn't exist, then *any* expression which evaluates to the
address of the object is undefined behavior.  But if no such expression
exists, there is no problem.

> Correct, but that doesn't mean the value of this has changed.  It
> no longer has a referrant.

> > [snip]
> > > An implementation can do whatever it wants. Maybe it knows that it
> > > can always use an address as a value (never dereferencing
> > > it). AFAIK profiling is a QOI issue and not covered by the
> > > standard.

> > The question is not whether implementation can do whatever it
> > wants. The question is whether implementation can do it and be
> > conforming. The answer is - yes, it can.

> I can easily imagine an implementation munging the memory that was
> just deleted.  But I can't imagine one modifying the argument to
> delete.  Still, you seem pretty convinced; to the point of making me
> unsure of my previous assumptions.  Can you provide a reference
> please?

I can't find the wording, so the standard may not allow it, but
traditionally, it was allowed in the case where the expression was an
lvalue.  This has no relevance to this, however, since this is not an
lvalue.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Gene Bushuyev" <gbush@my-Deja.com> writes:

>wmm@fastdial.net wrote in message <7r5ask$49h$1@nnrp1.deja.com>...
>[snip]
>>I think the answer _is_ clear from the Standard.  Agreed, there's
>>no place that the question of "delete this" is specifically addressed.
>>However, it does say that "this" is a pointer (9.3.2p1), and it says
>>that you can use "delete" with a pointer to an object that was
>>created by a new-expression (5.3.5p1).

>"this" is not just a pointer, it is a special kind of pointer (think, for
>example, what metamorphoses it comes through in constructor).

I can't think of any. In a typical implementation, on entry to a
constructor "this" is set to the address allocated for the object
(or subobject, for a base-class constructor) and never changes.

Maybe you are thinking of how an object's dynamic type changes
during construction. That has nothing to do with the "this"
pointer.  The type of "this" does not change in a constructor, and
I can see no reason for its value to change. When "this" is passed
to functions of other classes (such as base-class constructors)
the value that is passed must be adjusted to correspond to the
type conversion; the value of "this" itself is unaffected.

>There are
>certain qualifications in 9.3.2p1 that are specified for this pointer that
>contradict operator delete. Neither it is said anywhere that "this" is a
>pointer created by a new-expression.

The restrictions on using "delete" are that the address used match
in type and value what was obtained from a corresponding "new". As
long as those requirements are satisfied, I see no other restriction
that prevents "delete this" from being valid.

The standard does not require that any pointer be obtained from
a new-expression. If a pointer is in fact obtained from a new-
expression, you can use it in a delete-expression. There are some
additional restrictions, but none of them apply uniquely to "this".

Whenever "delete this" was discussed in the C++ committee, there
was no intention that it not be allowed. I suppose it is possible
that wording in the standard could be construed so as to disallow
it.  If that is the case, it is defect in the standard. But so far
you seem to have failed to persuade anyone that the standard
does not allow "delete this".

--
Steve Clamage, stephen.clamage@sun.com
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Marco Dalla Gasperina wrote in message ...
[snip]
>Are you saying that the implementation is allowed to change the
>value of the pointer deleted?  I don't see how that could be given
>that the argument to delete is an expression and not an lvalue.
>There is also no wording in [5.3.5] expr.delete (that I can see)
>which implies this.

See 5.3.5p4 the last phrase and note.

[snip]
>Correct, but that doesn't mean the value of this has changed.  It
>no longer has a referrant.

I think we are trying to play a word game. Standard, certainly, isn't
precise in this place and it may be the cause all these arguments. But we
have to work with what we have, even if those who wrote it meant
differently. If you follow the Occam's rule - the easiest and most direct
explanation is a correct one, then what 9.3.2p1 says is this:
when a member function is called, "this" is assigned a value equal to the
address of the object, and this value remains the same while in the body of
that member function and it always contains the address of the same object.


[snip]
>Can you provide a reference
>please?

Reference? What kind of reference? I'm aware that people were using "delete
this" from the time the language appeared. But it never was considered a
good practice. Scott Meyers in "More Effective C++" item 27 calls it
"infamous delete this." But, since, we have the Standard now, we have to
evaluate all the practices we have used before. Since allowing "delete this"
makes 9.3.2p1 meaningless at best and contradictory at worst I don't see how
it can be considered a safe practice.


Gene Bushuyev
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Gene Bushuyev" <gbush@my-Deja.com> writes:
> Yep, and the lifetime of "this" according to 9.3.2p1 is "the body of a
> nonstatic member function"

You know, even if your reading of the standard was correct, it wouldn't
make one bit of difference. The "delete this" idiom is useful and used.
If it could be derived from the standard that such usage was illegal,
then the standard would change, not the code, much in the same way that
vector's storage is going to be made contiguous. If an implementation
behaved in a way as to make "delete this" unsafe, the vendor would be
changed, not the code. Get over it.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev <gbush@my-deja.com> wrote in message
news:070672418040799CPIMSSMTPE01@msn.com...
> Marco Dalla Gasperina <marcodg@pacifier.com> wrote in message
> news:37d3f400.0@news.pacifier.com...
> [snip]
> > Even after 'delete this;' the keyword *this* still holds the address
> > of the object on which the the member function was called.  It just
> > happens not to be valid anymore.
>
> No, it doesn't. After "delete this" the value of "this" is undefined.
It can
> be anything. Moreover, since the object for which the member function
was
> called doesn't exist anymore, there is no way "this" can point to that
> object. The wording of the standard absolutely precludes it.

Actually, there is wording in the standard that says "this" still has
some useful attributes if the runtime library has not yet reclaimed the
memory.  This is a totally separate issue (since as consumer, we can't
guarantee this state), but one worth considering.

And I have to side with others who say that the context you quote does
not specifically state that "this" must remain valid throughout the life
of the function call.  It may be implied, but it may not, and the
context does not say either way.


However, this isn't what I asked for.  I specifically asked for a
definitive answer from the standard, and none has been given (although I
appreciate all the effort put into finding an answer!)

As Blargg noted in another group, I think the answer is that this is not
specifically addressed by the standard (paraphrasing, I hope
accurately).  However, it's also worth noting that many people have
indicated that many different compilers, on several platforms, implement
this behavior correctly ("this" is not referenced on the clients behalf
without their knowledge after deletion).  And in fact, on the Windows
platform this behavior is practically required, since most COM
implementations (being self-reference-counted objects) use "delete this"
to deallocate themselves.




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote in message <7r3kt8$pso$1@engnews1.eng.sun.com>...
[snip]
>I don't see anything in 9.3.2p1 that implies you cannot "delete this".
>It just says that "this" refers to the current object. If you delete
>the object, "this" has no referent, the same as for any pointer
>whose referent has been deleted.

I'm afraid I'm repeating myself. Please tell me, is the value of "this"
equal to "the address of the object for which the function is called" after
"delete this"? Are we still "in the body of a nonstatic member function"
after "delete this"? Whether it's intentional or not, this paragraph of the
standard requires "this" to be a valid pointer to same valid object as at
the moment the member function is called.
By the way what is "non-lvalue"? rvalue is non-lvalue, what else?
[snip]
>Example:
> queue *newqueue = oldqueue->cut();
> ...  // attach filter to newqueue and oldqueue
> newqueue->splice(oldqueue); // removes newqueue
>The library design could have been different, requiring additional
>operations to cut and spice so as not to require "delete this"


What hinders you to use non-member or static member funtions like these:
queue *newqueue  =  cut(oldqueue);
splice(newqueue, oldqueue); // removes newqueue
that do not have the problems with "delete this"?

Can you call it a good design anyway? What if the user of your library
decides to allocate an array of queues:
queue* ManyQueues = new queue[100];
for(...) ManyQueues[i]->cut();
Oops, you call delete for the objects that were allocated with new[].

Gene Bushuyev




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Gene Bushuyev" <gbush@synopsys.com> writes:


>Steve Clamage wrote in message <7r3kt8$pso$1@engnews1.eng.sun.com>...
>[snip]
>>I don't see anything in 9.3.2p1 that implies you cannot "delete this".
>>It just says that "this" refers to the current object. If you delete
>>the object, "this" has no referent, the same as for any pointer
>>whose referent has been deleted.

>I'm afraid I'm repeating myself. Please tell me, is the value of "this"
>equal to "the address of the object for which the function is called" after
>"delete this"? Are we still "in the body of a nonstatic member function"
>after "delete this"? Whether it's intentional or not, this paragraph of the
>standard requires "this" to be a valid pointer to same valid object as at
>the moment the member function is called.

I don't agree with your analysis. The standard makes many statements
that do not apply when preconditions are no longer true. This is
one of them, IMHO.

>>Example:
>> queue *newqueue = oldqueue->cut();
>> ...  // attach filter to newqueue and oldqueue
>> newqueue->splice(oldqueue); // removes newqueue
>>The library design could have been different, requiring additional
>>operations to cut and spice so as not to require "delete this"


>What hinders you to use non-member or static member funtions like these:
>queue *newqueue  =  cut(oldqueue);
>splice(newqueue, oldqueue); // removes newqueue
>that do not have the problems with "delete this"?

I suppose the library designers could have done that. I was
providing a 3rd-party implementation of a library that
originated elsewhere.

>Can you call it a good design anyway? What if the user of your library
>decides to allocate an array of queues:
>queue* ManyQueues = new queue[100];
>for(...) ManyQueues[i]->cut();
>Oops, you call delete for the objects that were allocated with new[].

No, the cut doesn't delete anything. It creates a (single) new queue,
which the corresponding splice deletes.

--
Steve Clamage, stephen.clamage@sun.com


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <07a4a4435040799CPIMSSMTPE01@msn.com>, "Gene Bushuyev"
<gbush@my-deja.com> wrote:

> Steve Clamage <clamage@eng.sun.com> wrote in message
> news:7r0ls7$d07$1@engnews1.eng.sun.com...
> [snip]
> > Assuming that memory leaks are undesirable, alternatives to
> > "delete this" would have been very complicated. I was quite
> > surprised to see "delete this" fall out of the basic design.
> > But it was easy to prove that it was appropriate and safe.
>
> Since I have already answered to the previous questions, I tackle only this
> one.
> 1) Firstly, I want to know, how can it be easy to prove that it is safe, if
> according to the standard 9.3.2p1 it is not safe.

I guess I missed the part that said "'delete this' is ill-formed".

> 2) Secondly, why whould excluding this practice complicate anything? One can
> always use static or non-member function to delete the object or use any of
> the garbage collection mechanisms to do that.

member function:

    struct Foobar {
        void f(); // may delete
    };

    void use( Foobar* x ) {
        x->f();
        // don't use x
    }

static function:

    struct Foobar {
        static void f( Foobar* ); // may delete
    };

    void use( Foobar* x ) {
        Foobar::f( x );
        // don't use x
    }

Guess there is no legitimate need for member functions either...

Either way you look at it, I don't see why you would think that the latter
(static) is superior to the former. If anything, there is no semantic
difference.

> 3) Thirdly, one of the requirements for good design is that the object that
> is responsible for creation of other object is also responsible for it's
> deletion.

Did you think someone was suggesting that one exclusively use "delete
this" in their designs (i.e. no other form of delete)?

> In the light of this, suicide is never a good practice. I'm
> surprised to hear that it was ever an element of "basic design." Can you
> address me to the literature where it is considered as a "basic design"
> feature?

    delete <pointer>

    this = pointer to object member function was invoked on

    put them together when appropriate

Do you think that deleting anything inside a member function is wrong?

    void use( Foo* foo, Bar* bar ) {
        foo->f();
        // foo deleted bar - don't use it
    }

Would this be "safer" if we used a static function?

        Foo::f( foo );
        // foo deleted bar - don't use it


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev <gbush@my-deja.com> claims:

> 1) (9.3.2p1) In the body of a nonstatic member function, the keyword "this"
> is a non-lvalue expression whose value is the address of the object for
> which the function is called.
> One of the ramifications of this is that compiler can expect "this" to be
> valid till the exit from the member function.

No, the compiler (like the programmer) must consider 3.8 [basic.life]
paragraph 3, "The properties ascribed to objects throughout this
International Standard apply for a given object only during its
lifetime."

To programmers, this is the rule which makes access to *p (or *this)
provoke undefined behavior after "delete p" is used.

To compilers, this rule forbids reliance on any property of *p after
"delete p" is used, except where the implementation provides stronger
guarantees than the standard.

                                                   --Lisa Lippincott


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev <gbush@my-deja.com> wrote in message
news:070672418040799CPIMSSMTPE01@msn.com...
> Marco Dalla Gasperina <marcodg@pacifier.com> wrote in message
> news:37d3f400.0@news.pacifier.com...
> [snip]
> > Even after 'delete this;' the keyword *this* still holds the address
> > of the object on which the the member function was called.  It just
> > happens not to be valid anymore.
>
> No, it doesn't. After "delete this" the value of "this" is undefined.
> It can be anything.

Are you saying that the implementation is allowed to change the
value of the pointer deleted?  I don't see how that could be given
that the argument to delete is an expression and not an lvalue.
There is also no wording in [5.3.5] expr.delete (that I can see)
which implies this.

> Moreover, since the object for which the member function was
> called doesn't exist anymore, there is no way "this" can point to that
> object. The wording of the standard absolutely precludes it.

Correct, but that doesn't mean the value of this has changed.  It
no longer has a referrant.

>
> [snip]
> > An implementation can do whatever it wants. Maybe it knows that it
> > can always use an address as a value (never dereferencing it).  AFAIK
> > profiling is a QOI issue and not covered by the standard.
>
> The question is not whether implementation can do whatever it wants. The
> question is whether implementation can do it and be conforming. The answer
> is - yes, it can.

I can easily imagine an implementation munging the memory that was
just deleted.  But I can't imagine one modifying the argument to
delete.  Still, you seem pretty convinced; to the point of making
me unsure of my previous assumptions.  Can you provide a reference
please?

marco




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Michael VanLoon <michaelv@edifecs.com> wrote in message
news:rt0f2id6h3640@corp.supernews.com...
> Consider this snip of code, a class with built-in reference counting
> semantics:
>
> class CRef
> {
>     public:
>     CRef() : m_iRefs(0) { }
>
>     // some members including AddRef()...
>
>     virtual int RemoveRef()
>     {
>         int iRef = --m_iRefs;
>         if (iRef == 0)
>             delete this;
>         return iRef;
>     }
>
>     protected:
>     virtual ~CRef() { }
>
>     private:
>     int m_iRefs;
> };
>
> Please don't address whether it's a good idea, or even "good style" --
> we're already hashing that out in a separate thread.
>
> I've been parsing through the standard, and I can't tell whether the
> behavior of RemoveRef() is undefined after delete or well defined.
>
> So, could a more seasoned veteran lend some insight into what exactly
> the standard says about this?  Please no opinions on what MIGHT
> happen -- we already have a boat-load of those -- I'm only interested
in
> facts (or at least well-reasoned theories from authoritative sources!
> :-).  Thanks.

Oh, also, if you could point me to where this information is hidden in
the standard, that would be much appreciated, as well.  If found things
that hint around it, but have not found the direct answer to this
question.





[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <rt0f2id6h3640@corp.supernews.com>, Michael VanLoon
<michaelv@edifecs.com> writes
>    virtual int RemoveRef()
>    {
>        int iRef = --m_iRefs;
>        if (iRef == 0)
>            delete this;
>        return iRef;
>    }
>
>    protected:
>    virtual ~CRef() { }
>
>    private:
>    int m_iRefs;
>};
>
>Please don't address whether it's a good idea, or even "good style" --
>we're already hashing that out in a separate thread.
>
>I've been parsing through the standard, and I can't tell whether the
>behavior of RemoveRef() is undefined after delete or well defined.

Why do you think it might be undefined?  The only thing you a prohibited
from doing after 'delete this' is to use, implicitly or explicitly,
'this'.  You have not done so (having carefully copied the value from
m_iRefs before possibly discarding the original).



Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow <francis@robinton.demon.co.uk> wrote in message
news:0PpofNAzuM03EwDO@robinton.demon.co.uk...
> Why do you think it might be undefined?  The only thing you a prohibited
> from doing after 'delete this' is to use, implicitly or explicitly,
> 'this'.  You have not done so (having carefully copied the value from
> m_iRefs before possibly discarding the original).

1) (9.3.2p1) In the body of a nonstatic member function, the keyword "this"
is a non-lvalue expression whose value is the address of the object for
which the function is called.
One of the ramifications of this is that compiler can expect "this" to be
valid till the exit from the member function. Therefore, if a profiling
compiler utilizes something like this it will be comforming to the standard:
void A::Fn()
{
   __start_timer(this);
  ...
  delete this;
  ...
  __stop_timer(this); // Access violation
}
2) there are no legitimate cases that would require deleting "this".

Gene Bushuyev





[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[This followup was also e-mailed to the cited author for speed -- please
follow up in the newsgroup.]

michaelv@edifecs.com (Michael VanLoon) wrote in comp.std.c++:
>Oh, also, if you could point me to where this information is hidden in
>the standard, that would be much appreciated, as well.  If found things
>that hint around it, but have not found the direct answer to this
>question.

Not the standard, but check section 16.14 of the FAQ
 http://www.cerfnet.com/~mpcline/c++-faq-lite/

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                                    http://www.mindspring.com/~brahms/
I don't need e-mail copies of posted follow-ups, but if you send
them PLEASE identify them as such.
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <0892e3007170499CPIMSSMTPE01@msn.com>, Gene Bushuyev
<gbush@my-deja.com> writes
>2) there are no legitimate cases that would require deleting "this".

It depends upon what you mean by legitimate.  AFAIK delete this occurs
in just about every GUI application framework.  If the standard really
does outlaw 'delete this' then I think it will need correcting with a DR
because I find it difficult to believe that it was intentional.

>

Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <0892e3007170499CPIMSSMTPE01@msn.com>, "Gene Bushuyev"
<gbush@my-deja.com> wrote:

> Francis Glassborow <francis@robinton.demon.co.uk> wrote in message
> news:0PpofNAzuM03EwDO@robinton.demon.co.uk...
> > Why do you think it might be undefined?  The only thing you a prohibited
> > from doing after 'delete this' is to use, implicitly or explicitly,
> > 'this'.  You have not done so (having carefully copied the value from
> > m_iRefs before possibly discarding the original).
>
> 1) (9.3.2p1) In the body of a nonstatic member function, the keyword "this"
> is a non-lvalue expression whose value is the address of the object for
> which the function is called.

OK

> One of the ramifications of this is that compiler can expect "this" to be
> valid till the exit from the member function.

Can you point to the reference in the standard where it says this?
Otherwise we got nothin' still :-(

> Therefore, if a profiling
> compiler utilizes something like this it will be comforming to the standard:
>
> void A::Fn()
> {
>    __start_timer(this);
>   ...
>   delete this;
>   ...
>   __stop_timer(this); // Access violation
> }
>
> 2) there are no legitimate cases that would require deleting "this".

Where legitimate = opinion. The original poster specifically wasn't
interested in opinion :-)


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev wrote:

> 2) there are no legitimate cases that would require deleting "this".

By the same resoning, there are no legitimes cases that would require
deleting anything.

--

Valentin Bonnard


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

blargg <postmast.root.admi.gov@iname.com> wrote in message
news:user-0509990739290001@aus-as3-008.io.com...
[snip]
>
> Can you point to the reference in the standard where it says this?
> Otherwise we got nothin' still :-(

The quoted portion of the standard is sufficient to make this conclusion. If
you want more on the same look at the previous posts.
[snip]
>
> Where legitimate = opinion. The original poster specifically wasn't
> interested in opinion :-)

What could it mean? Do you want to say that if it's somebodies (or maybe my)
oppinion then it is automatically wrong? Then what can we say about your
oppinion that it is my oppinion?
Everybody in this NG is expressing his/her oppinions, what else can we
express? The question is whether it is right or wrong. Your comment doesn't
address this. All you have to do to prove me wrong is to give one example
when "delete this" is required (that's what I meant by legitimate).

Gene Bushuyev





[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev <gbush@my-deja.com> wrote in message
news:0892e3007170499CPIMSSMTPE01@msn.com...
>
> Francis Glassborow <francis@robinton.demon.co.uk> wrote in message
> news:0PpofNAzuM03EwDO@robinton.demon.co.uk...
> > Why do you think it might be undefined?  The only thing you a prohibited
> > from doing after 'delete this' is to use, implicitly or explicitly,
> > 'this'.  You have not done so (having carefully copied the value from
> > m_iRefs before possibly discarding the original).
>
> 1) (9.3.2p1) In the body of a nonstatic member function, the keyword
"this"
> is a non-lvalue expression whose value is the address of the object for
> which the function is called.

Even after 'delete this;' the keyword *this* still holds the address
of the object on which the the member function was called.  It just
happens not to be valid anymore.

> One of the ramifications of this is that compiler can expect "this" to be
> valid till the exit from the member function. Therefore, if a profiling
> compiler utilizes something like this it will be comforming to the
standard:
> void A::Fn()
> {
>    __start_timer(this);
>   ...
>   delete this;
>   ...
>   __stop_timer(this); // Access violation
> }

An implementation can do whatever it wants. Maybe it knows that it
can always use an address as a value (never dereferencing it).  AFAIK
profiling is a QOI issue and not covered by the standard.

> 2) there are no legitimate cases that would require deleting "this".

Nothing is required... classes, tempates, for-loops, ... somethings
are easier if you have them, however.

marco
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Gene Bushuyev" <gbush@my-deja.com> writes:

>blargg <postmast.root.admi.gov@iname.com> wrote in message
>news:user-0509990739290001@aus-as3-008.io.com...
>>
>> Where legitimate = opinion. The original poster specifically wasn't
>> interested in opinion :-)

>What could it mean? Do you want to say that if it's somebodies (or maybe my)
>oppinion then it is automatically wrong? Then what can we say about your
>oppinion that it is my oppinion?
>Everybody in this NG is expressing his/her oppinions, what else can we
>express? The question is whether it is right or wrong. Your comment doesn't
>address this. All you have to do to prove me wrong is to give one example
>when "delete this" is required (that's what I meant by legitimate).

"delete this" is dangerous in general, and can result in undefined
behavior. Nevertheless, like other dangerous constructs, it can be
used when you can guarantee that the program doesn't cross into
the realm of undefined behavior.

Your use of "required" is problematic. Classes, inheritance, and
other C++ features are not "required", since people write good,
real-world programs in languages that do not have those features.

I think you want to ask whether the use of the feature is safe,
and whether alternative designs or coding would work as well
overall. (That is, taking into account maintenance issues as
well as efficiency concerns.)

In the days before STL, I implemented a version of the old AT&T
task library, whose interface allowed the user to split and merge
task queues. Splitting and merging meant that the library classes
managed structures on the heap that were invisible to the library
user.

The simplest way to handle merging was for the class member
function doing the final connection to delete its own object,
since there were no more references to it and the object itself
was unknown to the library user. The function was not directly
called by the library user.

Assuming that memory leaks are undesirable, alternatives to
"delete this" would have been very complicated. I was quite
surprised to see "delete this" fall out of the basic design.
But it was easy to prove that it was appropriate and safe.

--
Steve Clamage, stephen.clamage@sun.com
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Marco Dalla Gasperina <marcodg@pacifier.com> wrote in message
news:37d3f400.0@news.pacifier.com...
[snip]
> Even after 'delete this;' the keyword *this* still holds the address
> of the object on which the the member function was called.  It just
> happens not to be valid anymore.

No, it doesn't. After "delete this" the value of "this" is undefined. It can
be anything. Moreover, since the object for which the member function was
called doesn't exist anymore, there is no way "this" can point to that
object. The wording of the standard absolutely precludes it.

[snip]
> An implementation can do whatever it wants. Maybe it knows that it
> can always use an address as a value (never dereferencing it).  AFAIK
> profiling is a QOI issue and not covered by the standard.

The question is not whether implementation can do whatever it wants. The
question is whether implementation can do it and be conforming. The answer
is - yes, it can.

> > 2) there are no legitimate cases that would require deleting "this".
>
> Nothing is required... classes, tempates, for-loops, ... somethings
> are easier if you have them, however.

I don't see why there is so much problems with the word "required". It has
quite simple meaning; required by language or by good or necessary design.
Classes, templates, etc. are required not always, but  for certain designs.
Since object deletion can be performed by static or external to the class
functions, it's never an issue of design requirements.

Gene Bushuyev
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage <clamage@eng.sun.com> wrote in message
news:7r0ls7$d07$1@engnews1.eng.sun.com...
[snip]
> Assuming that memory leaks are undesirable, alternatives to
> "delete this" would have been very complicated. I was quite
> surprised to see "delete this" fall out of the basic design.
> But it was easy to prove that it was appropriate and safe.

Since I have already answered to the previous questions, I tackle only this
one.
1) Firstly, I want to know, how can it be easy to prove that it is safe, if
according to the standard 9.3.2p1 it is not safe.
2) Secondly, why whould excluding this practice complicate anything? One can
always use static or non-member function to delete the object or use any of
the garbage collection mechanisms to do that.
3) Thirdly, one of the requirements for good design is that the object that
is responsible for creation of other object is also responsible for it's
deletion. In the light of this, suicide is never a good practice. I'm
surprised to hear that it was ever an element of "basic design." Can you
address me to the literature where it is considered as a "basic design"
feature?

Gene Bushuyev
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Gene Bushuyev" <gbush@my-deja.com> writes:

>Steve Clamage <clamage@eng.sun.com> wrote in message
>news:7r0ls7$d07$1@engnews1.eng.sun.com...
>> Assuming that memory leaks are undesirable, alternatives to
>> "delete this" would have been very complicated. I was quite
>> surprised to see "delete this" fall out of the basic design.
>> But it was easy to prove that it was appropriate and safe.

>Since I have already answered to the previous questions, I tackle only this
>one.
>1) Firstly, I want to know, how can it be easy to prove that it is safe, if
>according to the standard 9.3.2p1 it is not safe.

I don't see anything in 9.3.2p1 that implies you cannot "delete this".
It just says that "this" refers to the current object. If you delete
the object, "this" has no referent, the same as for any pointer
whose referent has been deleted.

>2) Secondly, why whould excluding this practice complicate anything? One can
>always use static or non-member function to delete the object or use any of
>the garbage collection mechanisms to do that.
>3) Thirdly, one of the requirements for good design is that the object that
>is responsible for creation of other object is also responsible for it's
>deletion.  In the light of this, suicide is never a good practice. I'm
>surprised to hear that it was ever an element of "basic design." Can you
>address me to the literature where it is considered as a "basic design"
>feature?

I was implementing a 3rd-party design that I did not own.

The library design specified two complementary operations:
1. cutting a queue, which returned a pointer to a new queue
(on the heap) containing the items removed from the current queue;
2. splicing two queues, which by definition attached the current
queue's items to the other queue, removing the current queue.
The purpose of cutting a queue was to insert a filter into
the queue operations, which could be done without modifying
any other code accessing the queue.  Example:
 queue *newqueue = oldqueue->cut();
 ...  // attach filter to newqueue and oldqueue
 newqueue->splice(oldqueue); // removes newqueue
The library design could have been different, requiring additional
operations to cut and spice so as not to require "delete this"

Notice that this design encourages the cutter of the queue
to do the splicing, so that the owner of newqueue does in
fact delete it. But the deletion is done via the member
function that eliminates the need for newqueue.

The last operation of the splice function was "delete this". The
splice function was not called by any library function.  No library
code could possibly refer to "this" (or what it used to point to)
after the deletion.

By definition, the splice member function eliminates the current
queue, so the library user must not refer to it again. I don't
see any safety consideration for
 newqueue->splice(oldqueue);
that would be any different from
 delete newqueue;
In both cases, *newqueue ceases to exist, and it is the programmer's
responsibility not to refer to it again.

--
Steve Clamage, stephen.clamage@sun.com


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Consider this snip of code, a class with built-in reference counting
semantics:

class CRef
{
    public:
    CRef() : m_iRefs(0) { }

    // some members including AddRef()...

    virtual int RemoveRef()
    {
        int iRef = --m_iRefs;
        if (iRef == 0)
            delete this;
        return iRef;
    }

    protected:
    virtual ~CRef() { }

    private:
    int m_iRefs;
};

Please don't address whether it's a good idea, or even "good style" --
we're already hashing that out in a separate thread.

I've been parsing through the standard, and I can't tell whether the
behavior of RemoveRef() is undefined after delete or well defined.

So, could a more seasoned veteran lend some insight into what exactly
the standard says about this?  Please no opinions on what MIGHT
happen -- we already have a boat-load of those -- I'm only interested in
facts (or at least well-reasoned theories from authoritative sources!
:-).  Thanks.




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]