这是引用计数对象的核心习惯用法。

引用计数是一种强大的确定性垃圾收集形式——它确保对象管理自己的生命周期，而不是依赖“智能”指针等来为它们做这些。底层对象只能通过“Reference”智能指针访问，设计为指针在实际对象中递增或递减一个成员整数(引用计数)。

当最后一个引用退出堆栈或被删除时，引用计数将归零。对象的默认行为将是调用“delete this”来进行垃圾收集——我写的库在基类中提供了一个受保护的虚拟“CountIsZero”调用，这样你就可以为缓存之类的事情覆盖这个行为。

确保安全的关键是不允许用户访问相关对象的构造函数(使其受保护)，而是让他们调用一些静态成员——FACTORY——比如“static Reference CreateT(…)”。通过这种方式，你可以确定它们总是用普通的“new”构建的，并且没有原始指针可用，所以“delete this”永远不会爆炸。

好吧，在组件对象模型(COM)中，删除这个结构可以是Release方法的一部分，当你想释放被获取的对象时，它会被调用:

void IMyInterface::Release()
{
    --instanceCount;
    if(instanceCount == 0)
        delete this;
}

如果你害怕，有一个完全合法的破解方法:

void myclass::delete_me()
{
    std::unique_ptr<myclass> bye_bye(this);
}

我认为删除它是c++的惯用方法，我只是把它作为一种好奇来展示。

在某些情况下，这个构造实际上是有用的——您可以在抛出需要该对象成员数据的异常后删除该对象。对象在发生抛出之前一直有效。

void myclass::throw_error()
{
    std::unique_ptr<myclass> bye_bye(this);
    throw std::runtime_exception(this->error_msg);
}

注意:如果你使用的是c++ 11之前的编译器，你可以使用std::auto_ptr而不是std::unique_ptr，它会做同样的事情。

你可以这样做。然而，你不能给它赋值。因此，你陈述这样做的原因，“我想改变观点”，似乎很有问题。在我看来，更好的方法是让持有视图的对象替换该视图。

当然，你使用的是RAII对象所以你根本不需要调用delete，对吧?

这是允许的(只是在那之后不要使用对象)，但我不会在实践中编写这样的代码。我认为delete this应该只出现在调用release或release的函数中，看起来像:void release() {ref——;If (ref<1);}。

Yes, delete this; has defined results, as long as (as you've noted) you assure the object was allocated dynamically, and (of course) never attempt to use the object after it's destroyed. Over the years, many questions have been asked about what the standard says specifically about delete this;, as opposed to deleting some other pointer. The answer to that is fairly short and simple: it doesn't say much of anything. It just says that delete's operand must be an expression that designates a pointer to an object, or an array of objects. It goes into quite a bit of detail about things like how it figures out what (if any) deallocation function to call to release the memory, but the entire section on delete (§[expr.delete]) doesn't mention delete this; specifically at all. The section on destructors does mention delete this in one place (§[class.dtor]/13):

在定义虚析构函数时(包括隐式定义(15.8))，非数组释放函数的确定就像表达式delete this出现在析构函数类的非虚析构函数中一样(参见8.3.5)。

这倾向于支持标准考虑删除这个的想法;如果它是无效的，它的类型就没有意义。这是标准中唯一提到删除的地方;据我所知，根本没有。

不管怎样，有些人认为删除这条消息是一种恶意攻击，并告诉任何愿意听的人应该避免这样做。一个经常被引用的问题是很难确保类的对象只被动态分配。其他人认为这是一个非常合理的习语，并一直在使用它。就我个人而言，我介于两者之间:我很少使用它，但当它似乎是适合这项工作的工具时，不要犹豫。

The primary time you use this technique is with an object that has a life that's almost entirely its own. One example James Kanze has cited was a billing/tracking system he worked on for a phone company. When you start to make a phone call, something takes note of that and creates a phone_call object. From that point onward, the phone_call object handles the details of the phone call (making a connection when you dial, adding an entry to the database to say when the call started, possibly connect more people if you do a conference call, etc.) When the last people on the call hang up, the phone_call object does its final book-keeping (e.g., adds an entry to the database to say when you hung up, so they can compute how long your call was) and then destroys itself. The lifetime of the phone_call object is based on when the first person starts the call and when the last people leave the call -- from the viewpoint of the rest of the system, it's basically entirely arbitrary, so you can't tie it to any lexical scope in the code, or anything on that order.

对于任何可能关心这种编码的可靠性的人来说:如果你打电话到欧洲的任何地方，从欧洲的任何地方，或通过欧洲的任何地方，很有可能它是由代码处理的(至少是部分)。