Allan W wrote:
....
> And yet, you stated earlier that the C standard "officially" deprecates
> two features (as opposed to marking them obsolescent).

Yes, it deprecates them without defining what "deprecate" means. That's
not an unusual feature of that standard.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Sorry about the delay: I just discovered that this message got lost the
first time I tried to send it, four days ago.

Allan W wrote:
 > "James Kuyper Jr." (kuyper@wizard.net) wrote:
 >
 >>The old form is indeed still legal. There's only two items which are
 >>officially deprecated by the C standard, and this isn't one of them.
 >>However, section 6.11.7 does identify this feature as obsolescent. I
 >>don't think it makes much difference which term is used. In either case,
 >>the right behavior for programmers is to not use the feature in new
 >>code, and to mark it as something to be fixed in existing code.
 >
 >
 > Would you please tell us how the C standard defines obsolescent and
 > deprecated?  ...

It doesn't define 'deprecated' at all. Therefore, 3p1 applies: "Terms
not defined in this International Standard are to be interpreted
according to ISO/IEC 2382 1". I don't have a copy of that standard.

On the other hand, paragraph 2 of the Introduction to the C standard says:
"Certain features are _obsolescent_, which means that they may be
considered for withdrawal in future revisions of this International
Standard. They are retained because of their widespread use, but their
use in new implementations (for implementation features) or new programs
(for language [6.11] or library features [7.26]) is discouraged."

 > ... Would it be a good idea for the C++ standard to differentiate
 > between things that are obsolescent, and things that are deprecated?

Not being sure what the distinction is, I can't say.

 > For comparison purposes, the C++ standard defines deprecated as
 > "Normative for the current edition of the Standard, but not guaranteed
 > to be part of the Standard in future revisions."
 >
 > (Which is a little bit silly -- NOTHING is "guaranteed" to be part of
 > the Standard in future revisions -- but I think the point is made.)

Do you like the C wording for 'obsolescent' a little better? It seems to
meet your objection.

 > As for "obsolescent," the C++ Standard uses this phrase in 4 places,
 > all in Annex C. In all 4 cases, the word is used in a rationale,
 > explaining that some C-language feature that does not exist in C++
 > (or is deprecated in C++) is marked as obsolescent in C.

Therefore, the meaning for 'obsolescent' which is defined in the C
standard would be the one that applies.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net ("James Kuyper Jr.") wrote
> Sorry about the delay: I just discovered that this message got lost the
> first time I tried to send it, four days ago.
>
> Allan W wrote:
>  > Would you please tell us how the C standard defines obsolescent and
>  > deprecated?  ...
>
> It doesn't define 'deprecated' at all. Therefore, 3p1 applies: "Terms
> not defined in this International Standard are to be interpreted
> according to ISO/IEC 2382 1". I don't have a copy of that standard.

And yet, you stated earlier that the C standard "officially" deprecates
two features (as opposed to marking them obsolescent).

> On the other hand, paragraph 2 of the Introduction to the C standard says:
> "Certain features are _obsolescent_, which means that they may be
> considered for withdrawal in future revisions of this International
> Standard. They are retained because of their widespread use, but their
> use in new implementations (for implementation features) or new programs
> (for language [6.11] or library features [7.26]) is discouraged."

This seems to be exactly the intent of the phrase 'deprecated' in C++.

>  > ... Would it be a good idea for the C++ standard to differentiate
>  > between things that are obsolescent, and things that are deprecated?
>
> Not being sure what the distinction is, I can't say.

Neither can I... but I can hypothesize that there isn't any significant
difference.

>  > For comparison purposes, the C++ standard defines deprecated as
>  > "Normative for the current edition of the Standard, but not guaranteed
>  > to be part of the Standard in future revisions."
>  >
>  > (Which is a little bit silly -- NOTHING is "guaranteed" to be part of
>  > the Standard in future revisions -- but I think the point is made.)
>
> Do you like the C wording for 'obsolescent' a little better? It seems to
> meet your objection.

Yes!

Probably wouldn't want to change every usage of 'deprecated' in the C++
standard. It would make more sense to change C++'s definition of
deprecated, to match C's definition of obsolescent.

>  > As for "obsolescent," the C++ Standard uses this phrase in 4 places,
>  > all in Annex C. In all 4 cases, the word is used in a rationale,
>  > explaining that some C-language feature that does not exist in C++
>  > (or is deprecated in C++) is marked as obsolescent in C.
>
> Therefore, the meaning for 'obsolescent' which is defined in the C
> standard would be the one that applies.

The four uses are all non-normative; it explains WHY C++ is different
than C, and refers us to the C standard for more details. Therefore,
there is no need to define it in C++.

The real motivation for my questions was your observation that C
uses both 'deprecated' and 'obsolescent'. Although I didn't know if
there was any significant difference in these terms, it did occur
to me that using two different terms could be a good idea.
    One term (perhaps 'deprecated') would continue to mean, "you
       shouldn't use this in new programs, and we might not even
       support it in a future version of the standard.
    The other term (perhaps 'obsolescent') would now mean, "you
       shouldn't use this in new programs -- but this particular
       legacy probably won't soon be dropped from any standard."
       With the implication that it's okay for code generators to
       create code of this form.
I don't have many specifics on the way this would be used; it's just
a germ of an idea. But perhaps old-style casts would be obsolescent
instead of deprecated, so that code generators designed for both
C and C++ could use this feature. (Assumes that C++-style casts won't
soon make it into the C standard.)

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper Jr." (kuyper@wizard.net) wrote:
> The old form is indeed still legal. There's only two items which are
> officially deprecated by the C standard, and this isn't one of them.
> However, section 6.11.7 does identify this feature as obsolescent. I
> don't think it makes much difference which term is used. In either case,
> the right behavior for programmers is to not use the feature in new
> code, and to mark it as something to be fixed in existing code.

Would you please tell us how the C standard defines obsolescent and
deprecated? Would it be a good idea for the C++ standard to differentiate
between things that are obsolescent, and things that are deprecated?

For comparison purposes, the C++ standard defines deprecated as
"Normative for the current edition of the Standard, but not guaranteed
to be part of the Standard in future revisions."

(Which is a little bit silly -- NOTHING is "guaranteed" to be part of
the Standard in future revisions -- but I think the point is made.)

As for "obsolescent," the C++ Standard uses this phrase in 4 places,
all in Annex C. In all 4 cases, the word is used in a rationale,
explaining that some C-language feature that does not exist in C++
(or is deprecated in C++) is marked as obsolescent in C.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

nagle@animats.com (John Nagle) wrote
>      The long-lived languages (FORTRAN, COBOL, LISP,
> even C) were each, at some point, cleaned up, and
> non-trivially.  In each case, the changes were
> dramatically incompatible.  But they were needed
> to keep the language alive.

Are you referring to function declarations of the form

    int main(argc,argv) int argc; char**argv; {
       /* ... */
    }

Or do you mean something else?

AFAIK, the old form is deprecated but still legal. (I'm not certain
about this, though -- don't have the C standard.)

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

> Allan W wrote:
> > If you wish to champion the cause, please post some examples of why
> > "this reference" would be so much better than "this pointer".

musiphil@bawi.org (KIM Seungbeom) wrote
> Symmetry. Arguments of operator functions are always references.

I think you're saying that the code would look prettier if
"this" was a reference instead of a pointer.

I don't mean to trivialize that argument -- there's something to it.
But how would you implement trivial operator& if "this" was a reference?
The obvious way would cause endless recursion.

    Foo* Foo::operator&() { return &this; } // Endless recursion!

Maybe you would use a special syntax for "global operator&":

    Foo* Foo::operator&() { return ::&this; } // Yeech!

That looks even uglier than what you're trying to clean up... and
what's to stop non-member code from using the same operator?

    Foo* f = ::&foo_object; // Uh-oh...

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
....
> Are you referring to function declarations of the form
>
>     int main(argc,argv) int argc; char**argv; {
>        /* ... */
>     }
>
> Or do you mean something else?
>
> AFAIK, the old form is deprecated but still legal. (I'm not certain
> about this, though -- don't have the C standard.)

The old form is indeed still legal. There's only two items which are
officially deprecated by the C standard, and this isn't one of them.
However, section 6.11.7 does identify this feature as obsolescent. I
don't think it makes much difference which term is used. In either case,
the right behavior for programmers is to not use the feature in new
code, and to mark it as something to be fixed in existing code.


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

> John Nagle wrote:
> >     Of course, "this" really should be a reference, but,
> > as usual, it's too late to fix that.

witless@attbi.com (Witless) wrote
> Actually it is not too late.

Didn't you omit a smiley?

> If the standard permitted an implementation to offer the option
> of making this a reference

Oh -- an option! If by this you mean a compiler switch or setting,
then you'll be pleased to note that the standard already allows this.
The compiler has to be capable of implementing this as a reference,
to compile standards-compliant (backward-compatible, if you will)
code. If it ALSO has a switch to accept code in which "this" is a
reference instead, that's no skin off the standard's nose.

> new C++ and a lot of old C++ could be materially improved.

Hmmm... for new code, I think that "this" reference would have certain
minor advantages. I'm not convinced that it would be more type-safe,
although I suspect it might be. But I sure wouldn't go so far as to
say "materially" improved.

(Try it yourself!
    #define THIS (*this)
should work exactly as you seem to expect... if you can remove all
other references to "this" in your code, and you still feel you're
better off for it, you may be on to something!)

As for old code -- this is where I expected the smiley.
    this->member no longer compiles; you'd need THIS.member instead.
Furthermore, the very common statement
    return *this;
suddenly has to change to
    return this;
which might be easier to use, but breaks a lot of code. Worse still,
if your class has a unary operator*() defined, the first version silently
changes meaning...

> Eventually this as a pointer could be deprecated.  Or not.  Getting
> rid of this as a pointer is far less important than permitting
> this as a reference.
>
> There is not reasons whatsoever to forbid implementations from offering
> the option of handling this as a reference.

Except the one reason that applies to almost any change: legacy code.
Unlike some ideas, though, this one would affect a LOT of code -- unless
we used some new keyword for the reference this-pointer. Something like
Java's "self" or Visual Basic's "me", perhaps.

    assert(this == &self); // Always true by definition

But even in this version, we have that same worry (legacy). Adding a new
keyword always makes people nervous, for good reason... it can be overcome,
but there has to be a GOOD reason.

If you wish to champion the cause, please post some examples of why
"this reference" would be so much better than "this pointer". Have you
found a significant amount of code that needs an asterisk before "this"
but forgets to use it, and the compiler doesn't explain it well? My
own personal example would be in math-like operators:

    // If "THIS" was a reference
    Foo & Foo::operator+=(const Foo&rhs) {
        a += rhs.a;
        b += rhs.b; // Whatever...
        return THIS; // Instead of    return *this;
    }

Useful, yes. Compelling? ...Not sure.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
>
> If you wish to champion the cause, please post some examples of why
> "this reference" would be so much better than "this pointer".

Symmetry. Arguments of operator functions are always references.
An example:

class X {
    // ...
public:
    bool X::operator==(const X& that) const;
    bool X::operator!=(const X& that) const { return !(*this == that); }
};

Another example from my project code:

X::diff_type X::operator-(const X& that) const
{
    if (/* *this >= that */) { /* real calculation */ }
    else return - (that - *this); /* forwarding */
}

--
KIM Seungbeom <musiphil@bawi.org>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:

>>John Nagle wrote:
>>
>>>    Of course, "this" really should be a reference, but,
>>>as usual, it's too late to fix that.


     That sentiment isn't original with me; it's from
Strostrup.

     It's so terribly hard to get rid of legacy in this
language.  Yet it must, eventually, be done.

     The long-lived languages (FORTRAN, COBOL, LISP,
even C) were each, at some point, cleaned up, and
non-trivially.  In each case, the changes were
dramatically incompatible.  But they were needed
to keep the language alive.

     C++ needs a similar cleanup.  There's too much
legacy and cruft in this language.

     Ask of a feature "Given what we know now, would
we do it this way"?  If the answer is "No way",
a cleanup is appropriate.

     I'd argue that mechanical translation of legacy
code to the new form should be provided, but that
backwards compatibility for old code is unnecessary.

    John Nagle
    Animats

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:

>     Of course, "this" really should be a reference, but,
> as usual, it's too late to fix that.

Actually it is not too late.  If the standard permitted an implementation to
offer the option of making this a reference new C++ and a lot of old C++ could
be materially improved.  Eventually this as a pointer could be deprecated.  Or
not.  Getting rid of this as a pointer is far less important than permitting
this as a reference.

There is not reasons whatsoever to forbid implementations from offering the
option of handling this as a reference.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <7f2735a5.0212301316.42c0ef9c@posting.google.com>, Allan W
<allan_w@my-dejanews.com> writes
>Put it another way. One day I was working on a module and I added
>about a dozen new lines of code. When I compiled and tested, I
>discovered that the new code had no effect. Attempts to debug the
>new problem were quite frustrating until I realized that my new
>code had been inserted in the middle of a multi-line comment block.
>Given the fact that this was a real genuine error (not
>theoretical), would you propose banning all comments that resemble
>legal C++ code?

No, but I would advocate using an editor providing colour coded syntax.
Making the comments white on white would have shown the error pretty
fast. :-)


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Bob Bell" <belvis@pacbell.net> wrote in message
news:c87c1cfb.0212270717.59f8e1da@posting.google.com...
> kanze@gabi-soft.de (James Kanze) wrote in message
news:<d6651fb6.0212240129.21bcbf04@posting.google.com>...

> > > The difference is that "delete this" carries with it risks not present
> > > with its alternatives;
> >
> > What risks?
>
> The risk of surprising a caller of a member function by having the
> object disappear from him. The risk of calling (directly or
> indirectly) a member function which does "delete this" on a
> non-dynamic object such as an object on the stack.

    The "alternatives" proposed do not protect against any of those
situations.

    Besides, if a programmer calls a function, which deletes the object, and
then continues to access the object, surely the fault is not with the
language itself.

> Others have posted that they have never seen "delete this" used
> inappropriately or to otherwise have caused bugs. That has not been my
> experience. As I said, YMMV.

    Since 1997, when I started working for a company, with a considerable
code-base, compiled on 6 different platforms (Win32, Linux, FreeBSD,
Solaris, IRIX and OSF/1) I have not seen a single instance of "delete this"
being used incorrectly.

    Using "delete this" has a few "gotchas" but it's not unreasonable and it
is the only sane way to do certain things -- implement reference-counted
objects, which automatically delete themselves (COM interfaces, to name one
popular use for "delete this") for example.

> > > as well as being more symmetric -- it allows us to write object
> > > creation and deletion in the same place (which was the point of
> > > pairing "create" and "finish" in the example I gave).
> >
> > Destruction and creation aren't symmetric.  Nothing you can do will make
> > them so.  (Creation can use parameters, destruction no.  Destruction
> > always concerns an existing object, creation never.)
>
> My point was that you have object creation/deletion in the same
> place/scope/level in the system, as a way of simplifying
> understanding. As an extreme example, if Foo objects are created by a
> function in module A, but destroyed by a function in module B, that
> makes the system harder to understand. You find programmers creating
> objects with the A module function and then just deleting the object.
> Putting the object creation/deletion functions in the same place makes
> this kind of mistake less likely.

    Object creation and deletion functions are in the "same place"... They
are contained in the class, specifically in the constructors and
destructors. The question, is how one can access those functions.

   -n

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

belvis@pacbell.net (Bob Bell) wrote
> kanze@gabi-soft.de (James Kanze) wrote
> > belvis@pacbell.net (Bob Bell) wrote
> > > The difference is that "delete this" carries with it risks not present
> > > with its alternatives;
> >
> > What risks?
>
> The risk of surprising a caller of a member function by having the
> object disappear from him. The risk of calling (directly or
> indirectly) a member function which does "delete this" on a
> non-dynamic object such as an object on the stack.
>
> Others have posted that they have never seen "delete this" used
> inappropriately or to otherwise have caused bugs. That has not been my
> experience. As I said, YMMV.

A reference-counted class might use "delete this;" when the last
reference has been destroyed.

In most cases, when *client* code uses "delete this;" it indicates less
than stellar design. On the other hand, just because we recognize a
weak design doesn't mean we can fix it -- especially if (for instance)
our code has to fit into a third-party framework, such as Microsoft's
COM.

My main objection to making "delete this;" a compile-time error is
that it's not likely to catch an unwitting error. Consider a different
error:

    if (a=0) std::cout << "A is zero!\n";

The C++ standard says that this code is legal. Nevertheless, many
C++ compilers will issue a warning (not an error) for the above code,
because it's a common error to use assignment within a conditional
when equivalence was intended.

That same logic doesn't apply (in general) to "delete this;". Assume
for a moment that this is NOT what was intended -- what did the coder
actually intend? If I knew that there were pointer variables named
"thiss" or "his" then maybe I'd think that one of these variables was
intended. On the other hand, I think it's just as likely that the
user would type "delete his;" when s/he meant "delete this;". (The
latter error would be caught as an undeclared variable.)

Put it another way. One day I was working on a module and I added
about a dozen new lines of code. When I compiled and tested, I
discovered that the new code had no effect. Attempts to debug the
new problem were quite frustrating until I realized that my new
code had been inserted in the middle of a multi-line comment block.
Given the fact that this was a real genuine error (not
theoretical), would you propose banning all comments that resemble
legal C++ code?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Bob Bell" <belvis@pacbell.net> wrote in message
news:c87c1cfb.0212270717.59f8e1da@posting.google.com...
> kanze@gabi-soft.de (James Kanze) wrote in message
news:<d6651fb6.0212240129.21bcbf04@posting.google.com>...

> > > The difference is that "delete this" carries with it risks not present
> > > with its alternatives;
> >
> > What risks?
>
> The risk of surprising a caller of a member function by having the
> object disappear from him. The risk of calling (directly or
> indirectly) a member function which does "delete this" on a
> non-dynamic object such as an object on the stack.

    The "alternatives" proposed do not protect against any of those
situations.

    Besides, if a programmer calls a function, which deletes the object, and
then continues to access the object, surely the fault is not with the
language itself.

> Others have posted that they have never seen "delete this" used
> inappropriately or to otherwise have caused bugs. That has not been my
> experience. As I said, YMMV.

    Since 1997, when I started working for a company, with a considerable
code-base, compiled on 6 different platforms (Win32, Linux, FreeBSD,
Solaris, IRIX and OSF/1) I have not seen a single instance of "delete this"
being used incorrectly.

    Using "delete this" has a few "gotchas" but it's not unreasonable and it
is the only sane way to do certain things -- implement reference-counted
objects, which automatically delete themselves (COM interfaces, to name one
popular use for "delete this") for example.

> > > as well as being more symmetric -- it allows us to write object
> > > creation and deletion in the same place (which was the point of
> > > pairing "create" and "finish" in the example I gave).
> >
> > Destruction and creation aren't symmetric.  Nothing you can do will make
> > them so.  (Creation can use parameters, destruction no.  Destruction
> > always concerns an existing object, creation never.)
>
> My point was that you have object creation/deletion in the same
> place/scope/level in the system, as a way of simplifying
> understanding. As an extreme example, if Foo objects are created by a
> function in module A, but destroyed by a function in module B, that
> makes the system harder to understand. You find programmers creating
> objects with the A module function and then just deleting the object.
> Putting the object creation/deletion functions in the same place makes
> this kind of mistake less likely.

    Object creation and deletion functions are in the "same place"... They
are contained in the class, specifically in the constructors and
destructors. The question, is how one can access those functions.

   -n

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

belvis@pacbell.net (Bob Bell) wrote in message
news:<c87c1cfb.0212270717.59f8e1da@posting.google.com>...
> kanze@gabi-soft.de (James Kanze) wrote in message
> news:<d6651fb6.0212240129.21bcbf04@posting.google.com>...
> > belvis@pacbell.net (Bob Bell) wrote in message
> > news:<c87c1cfb.0212231416.549fbfc2@posting.google.com>...
> > > The difference is that "delete this" carries with it risks not
> > > present with its alternatives;

> > What risks?

> The risk of surprising a caller of a member function by having the
> object disappear from him.  The risk of calling (directly or
> indirectly) a member function which does "delete this" on a
> non-dynamic object such as an object on the stack.

Those risks are present anytime you pass a pointer, or even potentially
a reference.  There is nothing special about "this", as compared to any
other pointer.

The scenario is that an object receives an external (to it) event which
should trigger its demise.  Delete this isn't the only way to do this,
but it seems the most natural, and I've yet to see any alternatives
which offer any additional safety.  Any time an object is deleted, for
any reason, and by anyone, it must notify its clients.  If the only
client is the owner, and that owner is also the object generating the
event, then delete this is definitly optional, and the alternatives are
often better.  But at the application level, when talking about entity
objects which model external elements from the real world, there very
often isn't a logical "owner" for the object in the application.  One
can always create some sort of an object manager, but why?  What's the
advantage in calling myManager.deleteMe( this ), as opposed to simply
delete this?  (Sometimes, there may be an advantage, when for example
the manager can handle the notifications generically.  But this isn't a
universal.)

> Others have posted that they have never seen "delete this" used
> inappropriately or to otherwise have caused bugs. That has not been my
> experience. As I said, YMMV.

I don't think I've ever seen a feature which can't be misused, and a
general rule is that if something can be misused, it will be.  In
practice, I've seen a lot more problems with pointer arithmetic, or with
premature deletions from other causes, than with delete this.  But that
may be only because I've only seen delete this used sparingly, in
conjunction with various notification scenarios.  (At my late site,
there was code for a managed pointer which handled this.)

> > > as well as being more symmetric -- it allows us to write object
> > > creation and deletion in the same place (which was the point of
> > > pairing "create" and "finish" in the example I gave).

> > Destruction and creation aren't symmetric.  Nothing you can do will
> > make them so.  (Creation can use parameters, destruction no.
> > Destruction always concerns an existing object, creation never.)

> My point was that you have object creation/deletion in the same
> place/scope/level in the system, as a way of simplifying
> understanding. As an extreme example, if Foo objects are created by a
> function in module A, but destroyed by a function in module B, that
> makes the system harder to understand.

That depends on what the objects are doing.  It's certainly true for
some types of objects.  On the other hand, which are created in some
sort of factory method in one class, for the sole purpose of being used
by another class, often after having been passed around for awhile.
(This is one thing std::auto_ptr was designed for.)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

    Of course, "this" really should be a reference, but,
as usual, it's too late to fix that.

    John Nagle
    Animats

Allan W wrote:

> belvis@pacbell.net (Bob Bell) wrote
>
>>kanze@gabi-soft.de (James Kanze) wrote
>>
>>>belvis@pacbell.net (Bob Bell) wrote
>>>
>>>>The difference is that "delete this" carries with it risks not present
>>>>with its alternatives;

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) wrote in message news:<7f2735a5.0212241132.41728aa9@posting.google.com>...
> Are we all professionals here? Perhaps we can just say,
>     I know it can be misused, but it can also be used well, so
>     we shouldn't make it into an error.
> or else
>     I would never do that, but I realize that there are others who
>     would -- so I guess we shouldn't have that error message after all.
> and leave it at that? (I doubt it, but I hope I'm wrong...)

Funny -- I thought I was pretty much saying the second choice. I never
said it should be an error. (Well, I guess I left out the "I realize
that there are others who would" part.)

Bob Bell

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.de (James Kanze) wrote in message news:<d6651fb6.0212240129.21bcbf04@posting.google.com>...
> belvis@pacbell.net (Bob Bell) wrote in message
> news:<c87c1cfb.0212231416.549fbfc2@posting.google.com>...
> > The difference is that "delete this" carries with it risks not present
> > with its alternatives;
>
> What risks?

The risk of surprising a caller of a member function by having the
object disappear from him. The risk of calling (directly or
indirectly) a member function which does "delete this" on a
non-dynamic object such as an object on the stack.

Others have posted that they have never seen "delete this" used
inappropriately or to otherwise have caused bugs. That has not been my
experience. As I said, YMMV.

> > as well as being more symmetric -- it allows us to write object
> > creation and deletion in the same place (which was the point of
> > pairing "create" and "finish" in the example I gave).
>
> Destruction and creation aren't symmetric.  Nothing you can do will make
> them so.  (Creation can use parameters, destruction no.  Destruction
> always concerns an existing object, creation never.)

My point was that you have object creation/deletion in the same
place/scope/level in the system, as a way of simplifying
understanding. As an extreme example, if Foo objects are created by a
function in module A, but destroyed by a function in module B, that
makes the system harder to understand. You find programmers creating
objects with the A module function and then just deleting the object.
Putting the object creation/deletion functions in the same place makes
this kind of mistake less likely.

Bob Bell

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.de (James Kanze) writes:

> I'll second that.  It's not the sort of error you make by chance.  Maybe
> if you happen to have pointer variables named thsi, or something else
> where a simple typo will result in this.  But even then, most editors
> display keywords (including this) in a different color, so you see the
> mistake immediately.
>
> I suspect that when someone declares that most uses of delete this are
> in error, they are talking about a design error (or what they consider
> such).

One of the reasons I would oppose any proposal to ban 'delete this' is
that even if you do think it's always an error, there's no possibility
that it could be banned in any useful way.

I agree with you that the literal sequence of tokens 'delete this;' is
extremely unlikely to be an error, because it's not the sort of thing
you would just write by accident.  What's more likely to be an error
is 'delete p' where p happens to be equal to 'this'.  But, of course,
that couldn't very well be banned, since any pointer of the
appropriate type might be equal to 'this'.  We couldn't very well ask
the compiler to do a global data flow analysis and have it issue an
error message unless it can prove that 'p' and 'this' aren't aliased!
The most we could do is say that 'delete p' is undefined behavior when
p happens to equal 'this', but I don't think that adding another kind
of undefined behavior would be doing users a service.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

belvis@pacbell.net (Bob Bell) wrote
> shannon.barber@myrealbox.com (Shannon Barber) wrote
> > That's not a valid argument.  Just because it is not required does not
> > mean it is not useful.  Since we have goto, for, while, & do are not
> > needed.  ++ is not needed, you can just write i=i+1. bogus arguments
> > ad nauseam...
>
> The difference is that "delete this" carries with it risks not present
> with its alternatives; for, while and do carry no such risks compared
> to goto.

   unsigned int x = 0;
   for (unsigned int y=10; y>=0; --y) { // Error

> > Besides, your proposed implementation does the exact same thing delete
> > this does.  It's purely a stylistic difference, except your way is
> > more work and not current convention.
>
> The alternative principle I was proposing was to have object lifetime
> managed outside of non-static member functions. Doing this avoids the
> risks inherent in "delete this," as well as being more symmetric -- it
> allows us to write object creation and deletion in the same place
> (which was the point of pairing "create" and "finish" in the example I
> gave).

Making "delete this" generate an error, won't prevent people from
creating workarounds to accomplish the same thing. Horror stories
notwithstanding, many people who have tried it have been successful
and have found it to be useful; see for example anyone who has ever
created a COM component on Windows.

Basically the only consistent error in "delete this" is offending
the sensibilities of some people that like their designs more "pure."

> > Perhaps there is some benefit that eludes me?
>
> See above. Further, I would ask "perhaps there is some benefit [to
> "delete this"] that eludes me?" What benefits does "delete this" bring
> that outweigh its disadvantages?

Reference-counted objects. Linked-list items that know how to
erase themselves from a list.

"delete this" might be ugly, but it's used far more than you like,
and turning it into an error would break a lot of legacy code.
Furthermore, the error wouldn't prevent people from using the pattern,
it would just require them from using the most convenient syntax
(which AFAIK is never done by accident anyway).

> However, I'm not really interested in starting a religious war over
> "delete this". Some people think it's OK, others don't. I happen to
> fall into the "don't" category. YMMV.

I happen to think it's overused, but that's far different from
"the don't category".

As for the religious war -- it's already a religious skirmish, and
I see the troops a-gatherin'. Stopping the batle now is well neigh
impossible... there is going to be a lot of heat on both sides, but
nobody is going to convince anyone else to change their opinion.
I give it 2 weeks before someone posts something vaguely similar to,

    > >> It's W all over again -- it's always been W, and it always
    > >> will be W
    > >But that's not what you said yesterday:
    > >>> for either X or Y, but never W under any circumstances
    > >So which is it really?
    > You're taking me out of context. When I said "never W" I was
    > referring to Z, not S. It's all because you said U and V,
    > completely ignoring W. But W is the way, the truth and the light.
    > And you still haven't answered my question about T, except to
    > say that it isn't W.
    I've already answered the T question three times -- and I never
    said it isn't W. See my earlier post for thorough details.

and so on until somebody promises never to post here again (or at
least, never on this thread) and huffs away.

Are we all professionals here? Perhaps we can just say,
    I know it can be misused, but it can also be used well, so
    we shouldn't make it into an error.
or else
    I would never do that, but I realize that there are others who
    would -- so I guess we shouldn't have that error message after all.
and leave it at that? (I doubt it, but I hope I'm wrong...)

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

scottm@toast.net ("Scott Mayo") wrote
> I don't care if 98% of the time delete this; is a mistake - in
> that case, go ahead and suggest as a common extension
> that compilers raise a warning when it is used. Warnings are
> always acceptable.

My biggest problem with making "delete this" an error, is that
it's unlikely to be written by accident -- anyone who writes
that line knows exactly what to expect.

(I'll grant that people might not have thought it out -- if
"delete this" was in a member function that was called by other
member functions, they might not realize the implications. But
they certainly know what it did in the function that did the
delete!)

Has anyone ever seen code that ACCIDENTALLY said "delete this" but
didn't mean to?

What's more important, IMHO, is to catch cases of "delete that"
where "that" happens to equal this. It could happen, for instance,
in a bad implementation of reference counting which doesn't check
for self-assignment.

Far fetched? Perhaps. But so is the idea that someone would type
"delete this" without at least knowing the most direct result
of such code. If they think they know what they're doing, then
forcing them to play games (such as create static member functions
that do the deletion) isn't going to prevent them from trying.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

scottm@toast.net ("Scott Mayo") wrote in message news:<3e02ca0c@news.toast.net>...
> "John Nagle" <nagle@animats.com> wrote in message
> news:3E02AEFA.6020405@animats.com...
>
> >     To make this more concrete, consider the following changes:
> >
> > -- Disallow overriding of a non-virtual function.
> > -- Disallow delete of const pointers.
> > -- Disallow "delete this".
> >
> >     These are all things that are usually errors.
>
> delete this; is not an error. I use it. I create an object for
> the calling app, and reject attempts to delete it unless it
> is in a certain state. I do this by making the constructor and
> destructor private, and having a finish() method that checks
> the state and, if all is well, calls delete this; as the last
> operation. (And yes, this class is by design not extensible,
> and would be a perfect candidate for final!) I bet
> other people have solved the same problem the same way.
>
> I don't care if 98% of the time delete this; is a mistake - in
> that case, go ahead and suggest as a common extension
> that compilers raise a warning when it is used. Warnings are
> always acceptable.
>
> Of course I could code around such a new restriction,
> using a friend class and some slightly obscurity. But why?
> delete this; return; describes my intent exactly!

So does:

class Foo {

   public:

      static Foo* create();
      static void finish(Foo*);

   private:

      Foo();
      ~Foo();

};

No need for delete this;

Bob Bell

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In fact, "delete this" is very common when you uses ATL to create COM
objects (and most alternatives including COM programming by hand) will do a
delete this when releasing the last reference to the object.

And as mentionned, it is very easy to do the same effect indirectly... One
could do something like:

template <typename T> void DeleteThis(T *p) { delete p; }
#define DELETE_THIS DeleteThis(this)

and uses it that way:

void SomeClass::DestroyMyself() {
    DELETE_THIS;    // or alternatively DeleteThis(this);
}

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

belvis@pacbell.net (Bob Bell) wrote in message news:<c87c1cfb.0212201546.5f0f8d9c@posting.google.com>...
> > Of course I could code around such a new restriction,
> > using a friend class and some slightly obscurity. But why?
> > delete this; return; describes my intent exactly!
>
> So does:
>
> class Foo {
>
>    public:
>
>       static Foo* create();
>       static void finish(Foo*);
>
>    private:
>
>       Foo();
>       ~Foo();
>
> };
>
> No need for delete this;
>

so anytime anyone ever wants to "delete this", they'll simply write
this:

template <typename T> inline void delete_this(const T* that) {
 delete that;
}

delete_this(this);

in other words, if there is such an easy work-around, then the "rule"
is useless.

I've never seen "delete this" used incorrectly.  I've only ever used
it for reference counted classes, where the "Release" methoed
decrements the count, and calls "delete this" if the count becomes 0.

joshua lehrer
factset research systems

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bob Bell wrote:
>       static void finish(Foo*);

In what way does forcing someone to utter "finish(this)" as opposed
to "delete this" have any salutary effect?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

belvis@pacbell.net (Bob Bell) wrote
> >
> > Of course I could code around such a new restriction,
> > using a friend class and some slightly obscurity. But why?
> > delete this; return; describes my intent exactly!
>
> So does:
>
> class Foo {
>
>    public:
>
>       static Foo* create();
>       static void finish(Foo*);
>
>    private:
>
>       Foo();
>       ~Foo();
>
> };
>
> No need for delete this;
>

That's not a valid argument.  Just because it is not required does not
mean it is not useful.  Since we have goto, for, while, & do are not
needed.  ++ is not needed, you can just write i=i+1. bogus arguments
ad nauseam...

Besides, your proposed implementation does the exact same thing delete
this does.  It's purely a stylistic difference, except your way is
more work and not current convention.

Perhaps there is some benefit that eludes me?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

usenet_cpp@lehrerfamily.com (Joshua Lehrer) wrote in message
news:<31c49f0d.0212212004.1e0c8a55@posting.google.com>...
> belvis@pacbell.net (Bob Bell) wrote in message
> news:<c87c1cfb.0212201546.5f0f8d9c@posting.google.com>...

> > > Of course I could code around such a new restriction, using a
> > > friend class and some slightly obscurity. But why?  delete this;
> > > return; describes my intent exactly!

> > So does:

> > class Foo {

> >    public:

> >       static Foo* create();
> >       static void finish(Foo*);

> >    private:

> >       Foo();
> >       ~Foo();

> > };

> > No need for delete this;

No need for saying what you mean?

    [...]

> I've never seen "delete this" used incorrectly.

I'll second that.  It's not the sort of error you make by chance.  Maybe
if you happen to have pointer variables named thsi, or something else
where a simple typo will result in this.  But even then, most editors
display keywords (including this) in a different color, so you see the
mistake immediately.

I suspect that when someone declares that most uses of delete this are
in error, they are talking about a design error (or what they consider
such).

    [...]

> I've only ever used it for reference counted classes, where the
> "Release" methoed decrements the count, and calls "delete this" if the
> count becomes 0.

I use it there, but I also use it extensively with entity objects which
model something in the real world.  The entity object is notified of
events affecting the real world object, and responds accordingly.
Including in the case where the real world object ceases to exist (or
simply ceases to be relevent to the model).

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

shannon.barber@myrealbox.com (Shannon Barber) wrote in message news:<de001473.0212221942.24a854ba@posting.google.com>...
> belvis@pacbell.net (Bob Bell) wrote
> > >
> > > Of course I could code around such a new restriction,
> > > using a friend class and some slightly obscurity. But why?
> > > delete this; return; describes my intent exactly!
> >
> > So does:
> >
> > class Foo {
> >
> >    public:
> >
> >       static Foo* create();
> >       static void finish(Foo*);
> >
> >    private:
> >
> >       Foo();
> >       ~Foo();
> >
> > };
> >
> > No need for delete this;
> >
>
> That's not a valid argument.  Just because it is not required does not
> mean it is not useful.  Since we have goto, for, while, & do are not
> needed.  ++ is not needed, you can just write i=i+1. bogus arguments
> ad nauseam...

The difference is that "delete this" carries with it risks not present
with its alternatives; for, while and do carry no such risks compared
to goto.

> Besides, your proposed implementation does the exact same thing delete
> this does.  It's purely a stylistic difference, except your way is
> more work and not current convention.

The alternative principle I was proposing was to have object lifetime
managed outside of non-static member functions. Doing this avoids the
risks inherent in "delete this," as well as being more symmetric -- it
allows us to write object creation and deletion in the same place
(which was the point of pairing "create" and "finish" in the example I
gave).

> Perhaps there is some benefit that eludes me?

See above. Further, I would ask "perhaps there is some benefit [to
"delete this"] that eludes me?" What benefits does "delete this" bring
that outweigh its disadvantages?

However, I'm not really interested in starting a religious war over
"delete this". Some people think it's OK, others don't. I happen to
fall into the "don't" category. YMMV.

Bob Bell

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

belvis@pacbell.net (Bob Bell) wrote in message
news:<c87c1cfb.0212231416.549fbfc2@posting.google.com>...
> shannon.barber@myrealbox.com (Shannon Barber) wrote in message
> news:<de001473.0212221942.24a854ba@posting.google.com>...
> > belvis@pacbell.net (Bob Bell) wrote

> > > > Of course I could code around such a new restriction, using a
> > > > friend class and some slightly obscurity. But why?  delete this;
> > > > return; describes my intent exactly!

> > > So does:

> > > class Foo {

> > >    public:

> > >       static Foo* create();
> > >       static void finish(Foo*);

> > >    private:

> > >       Foo();
> > >       ~Foo();

> > > };

> > > No need for delete this;

> > That's not a valid argument.  Just because it is not required does
> > not mean it is not useful.  Since we have goto, for, while, & do are
> > not needed.  ++ is not needed, you can just write i=i+1. bogus
> > arguments ad nauseam...

> The difference is that "delete this" carries with it risks not present
> with its alternatives;

What risks?

> for, while and do carry no such risks compared to goto.

> > Besides, your proposed implementation does the exact same thing
> > delete this does.  It's purely a stylistic difference, except your
> > way is more work and not current convention.

> The alternative principle I was proposing was to have object lifetime
> managed outside of non-static member functions. Doing this avoids the
> risks inherent in "delete this,"

What risks?  I don't see any risks particularly inherent in "delete
this" that aren't present in the alternatives.

> as well as being more symmetric -- it allows us to write object
> creation and deletion in the same place (which was the point of
> pairing "create" and "finish" in the example I gave).

Destruction and creation aren't symmetric.  Nothing you can do will make
them so.  (Creation can use parameters, destruction no.  Destruction
always concerns an existing object, creation never.)

> > Perhaps there is some benefit that eludes me?

> See above. Further, I would ask "perhaps there is some benefit [to
> "delete this"] that eludes me?" What benefits does "delete this" bring
> that outweigh its disadvantages?

It puts the statement where it logically belongs.  (Where the decision
is made, if you prefer.)  And since I can't see any disadvantages to put
against it.  (Code like the above is simple obfuscation.)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:3E02AEFA.6020405@animats.com...

>     To make this more concrete, consider the following changes:
>
> -- Disallow overriding of a non-virtual function.
> -- Disallow delete of const pointers.
> -- Disallow "delete this".
>
>     These are all things that are usually errors.

delete this; is not an error. I use it. I create an object for
the calling app, and reject attempts to delete it unless it
is in a certain state. I do this by making the constructor and
destructor private, and having a finish() method that checks
the state and, if all is well, calls delete this; as the last
operation. (And yes, this class is by design not extensible,
and would be a perfect candidate for final!) I bet
other people have solved the same problem the same way.

I don't care if 98% of the time delete this; is a mistake - in
that case, go ahead and suggest as a common extension
that compilers raise a warning when it is used. Warnings are
always acceptable.

Of course I could code around such a new restriction,
using a friend class and some slightly obscurity. But why?
delete this; return; describes my intent exactly!




---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]