Jaki jest pożytek z posiadania destruktora jako prywatnego?

Taki obiekt nie może być utworzony na stosie. Zawsze na stosie. A usunięcie musi zostać dokonane za pośrednictwem znajomego lub członka. Produkt może używać jednej hierarchii obiektów i niestandardowego Menedżera pamięci -- takie scenariusze mogą używać prywatnego dtor.

#include <iostream>
class a {
    ~a() {}
    friend void delete_a(a* p);
};


void delete_a(a* p)  {
    delete p;
}

int main()
{
    a *p = new a;
    delete_a(p);

    return 0;
}

Jeśli nie chcesz, aby użytkownicy mieli dostęp do destruktora, tzn. chcesz, aby obiekt został zniszczony tylko innymi środkami.

Http://blogs.msdn.com/larryosterman/archive/2005/07/01/434684.aspx podaje przykład, w którym obiekt jest liczony jako reference i powinien być niszczony przez sam obiekt tylko wtedy, gdy zliczanie idzie do zera.

COM używa tej strategii do usuwania instancji. COM czyni Destruktor prywatnym i zapewnia interfejs do usuwania instancji.

Oto przykład jak wyglądałaby metoda Release.

int MyRefCountedObject::Release() 
{
 _refCount--;
 if ( 0 == _refCount ) 
 {
    delete this;
    return 0;
 }
 return _refCount;
}

Dodanie do odpowiedzi już tutaj obecnych; prywatne konstruktory i destruktory są bardzo przydatne podczas implementacji factory gdzie utworzone obiekty muszą być przydzielone na stercie. Obiekty te byłyby ogólnie tworzone/usuwane przez statycznego członka lub przyjaciela. Przykład typowego użycia:

class myclass
{
public:
    static myclass* create(/* args */)  // Factory
    {
        return new myclass(/* args */);
    }

    static void destroy(myclass* ptr)
    {
        delete ptr;
    }
private:
    myclass(/* args */) { ... }         // Private CTOR and DTOR
    ~myclass() { ... }                  // 
}

int main ()
{
    myclass m;                          // error: ctor and dtor are private
    myclass* mp = new myclass (..);     // error: private ctor
    myclass* mp = myclass::create(..);  // OK
    delete mp;                          // error: private dtor
    myclass::destroy(mp);               // OK
}

Klasa może zostać usunięta tylko sama. Przydatne, jeśli tworzysz jakiś obiekt z liczeniem referencji. Wtedy tylko metoda release może usunąć obiekt, co może pomóc uniknąć błędów.

Wiem, że pytałeś o prywatnego niszczyciela. Oto, jak używam chronionych. Chodzi o to, że nie chcesz usuwać głównej klasy za pomocą wskaźnika do klasy, która dodaje dodatkową funkcjonalność do głównej.
W poniższym przykładzie nie chcę, aby GuiWindow był usuwany przez wskaźnik HandlerHolder.

class Handler
{
public:
    virtual void onClose() = 0;
protected:
    virtual ~Handler();
};

class HandlerHolder
{
public:
    void setHandler( Handler* );
    Handler* getHandler() const;
protected:
    ~HandlerHolder(){}
private:
    Handler* handler_;
};

class GuiWindow : public HandlerHolder
{
public:
    void finish()
    {
        getHandler()->onClose();
    }

    virtual ~GuiWindow(){}
};

Dirkgently jest w błędzie. Oto przykład obiektu z prywatnymi c-tor I d-tor utworzonymi na stosie(używam tutaj statycznej funkcji member, ale można to zrobić również za pomocą funkcji friend lub friend class).

#include <iostream>

class PrivateCD
{
private:
    PrivateCD(int i) : _i(i) {};
    ~PrivateCD(){};
    int _i;
public:
    static void TryMe(int i)
    {
        PrivateCD p(i);
        cout << "inside PrivateCD::TryMe, p._i = " << p._i << endl;
    };
};

int main()
{
    PrivateCD::TryMe(8);
};

Ten kod wygeneruje wyjście: inside PrivateCD:: TryMe, p. _i = 8

Może to być sposób na rozwiązanie problemu w systemie Windows, w którym każdy moduł może używać innej sterty, takiej jak sterta Debugowania . Jeśli problem nie został poprawnie rozwiązany bad rzeczy mogą się zdarzyć.