C ++에서 순수한 가상 소멸자가 필요한 이유는 무엇입니까?

가상 소멸자가 필요하다는 것을 이해합니다. 그러나 왜 순수한 가상 소멸자가 필요한가? C ++ 기사 중 하나에서 저자는 클래스 추상을 만들 때 순수한 가상 소멸자를 사용한다고 언급했습니다.

그러나 멤버 함수 중 하나를 순수 가상으로 만들어 클래스 추상화를 만들 수 있습니다.

그래서 내 질문은

1. 우리는 언제 소멸자를 순수 가상으로 만들까요? 누구든지 좋은 실시간 예를 들어 줄 수 있습니까?

2. 추상 클래스를 만들 때 소멸자를 가상으로 만드는 것이 좋은 습관입니까? 그렇다면 왜 그렇습니까?

1. 아마도 순수한 가상 소멸자가 허용되는 실제 이유는 언어에 다른 규칙을 추가한다는 것을 금지한다는 것입니다. 순수한 가상 소멸자를 허용하는 데 악영향을 미치지 않기 때문에이 규칙이 필요하지 않기 때문입니다.

2. 아니, 평범한 오래된 가상이면 충분합니다.

가상 메소드에 대한 기본 구현으로 오브젝트를 작성하고 누군가가 특정 메소드 를 대체하지 않고 추상화 하도록하려면 소멸자를 순수한 가상으로 만들 수 있습니다. 나는 그 점을 많이 보지 못하지만 가능합니다.

컴파일러는 파생 클래스에 대한 암시 적 소멸자를 생성하므로 클래스 작성자가 그렇게하지 않으면 파생 클래스가 추상화 되지 않습니다 . 따라서 기본 클래스에 순수한 가상 소멸자가 있으면 파생 클래스에 아무런 차이가 없습니다. 기본 클래스만을 추상화합니다 ( @kappa 의 의견에 감사드립니다 ).

또한 모든 파생 클래스는 특정 정리 코드가 필요하고 순수 가상 소멸자를 사용하여 코드를 작성하라는 알림으로 사용해야하지만 가정 된 것입니다 (강제되지 않음).

주 : 소멸자가 있더라도 유일한 방법 인 순수 가상 갖는다 인스턴스화는 (예 순수 가상 함수의 구현을 가질 수있다) 클래스를 유도하기 위해 구현하도록.

struct foo {
    virtual void bar() = 0;
};

void foo::bar() { /* default implementation */ }

class foof : public foo {
    void bar() { foo::bar(); } // have to explicitly call default implementation.
};

추상 클래스에 필요한 것은 하나 이상의 순수 가상 함수입니다. 모든 기능이 수행됩니다. 그러나 소멸자는 모든 클래스가 가질 수있는 것이므로 항상 후보로 존재합니다. 또한 소멸자를 순수 가상 (가상과 반대)으로 만드는 것은 클래스 추상화를 만드는 것 외에는 행동상의 부작용이 없습니다. 따라서 많은 스타일 가이드는 순수 가상 Destuctor를 일관되게 사용하여 클래스가 추상임을 표시하도록 권장합니다. 다른 이유가 없다면 코드를 읽는 사람이 클래스가 추상인지 확인할 수있는 일관된 위치를 제공하는 경우입니다.

추상 기본 클래스를 작성하려면 다음을 수행하십시오.

• 그 인스턴스화 할 수없는 (네,이 용어는 "추상적"와 중복!)
• 그러나 가상 소멸자 동작이 필요 합니다 (유도 된 유형에 대한 포인터가 아닌 ABC에 대한 포인터를 들고 삭제하려고합니다)
• 그러나 다른 메소드에는 다른 가상 디스패치 동작이 필요하지 않습니다 (다른 메소드 가 없을 수도 있습니다 . 생성자 / 소멸자 / 할당이 필요하지만 그다지 많지 않은 간단한 보호 된 "자원"컨테이너를 고려하십시오)

... 그것은 소멸자가 순수 가상하여 클래스 추상적를 만들기 위해 가장 쉬운 방법 과 그것을 위해 정의 (메서드 본문)를 제공한다.

우리의 가상 ABC의 경우 :

클래스 자체 내부에서도 인스턴스화 할 수 없다는 것을 보장합니다 (이것은 개인 생성자가 충분하지 않은 이유입니다). 소멸자를 위해 원하는 가상 동작을 얻습니다. 그렇지 않은 다른 메소드를 찾아 태그를 지정할 필요가 없습니다. "가상"으로 가상 디스패치가 필요하지 않습니다.

내가 읽은 대답에서 귀하의 질문에 실제로 순수한 가상 소멸자를 사용하는 좋은 이유를 추론 할 수 없었습니다. 예를 들어 다음과 같은 이유로 전혀 확신하지 못합니다.

아마도 순수한 가상 소멸자가 허용되는 실제 이유는 언어에 다른 규칙을 추가한다는 것을 금지한다는 것입니다. 순수한 가상 소멸자를 허용하는 데 악영향을 미치지 않기 때문에이 규칙이 필요하지 않기 때문입니다.

제 생각에는 순수한 가상 소멸자가 유용 할 수 있습니다. 예를 들어, 코드에 myClassA 및 myClassB라는 두 개의 클래스가 있고 myClassB가 myClassA에서 상속한다고 가정합니다. Scott Meyers가 자신의 저서 "더 효과적인 C ++", 항목 33 "비 리프 클래스 추상 만들기"에서 언급 한 이유 때문에 myClassA 및 myClassB가 상속하는 추상 클래스 myAbstractClass를 실제로 만드는 것이 좋습니다. 이것은 더 나은 추상화를 제공하고 예를 들어 객체 복사로 인해 발생하는 일부 문제를 방지합니다.

추상화 프로세스 (myAbstractClass 클래스 작성)에서 myClassA 또는 myClassB의 메소드가 순수한 가상 메소드 (myAbstractClass가 추상적이되기위한 전제 조건)가 될 수있는 좋은 후보가 될 수는 없습니다. 이 경우 추상 클래스의 소멸자 순수 가상을 정의합니다.

이후에는 내가 작성한 일부 코드의 구체적인 예가 있습니다. 공통 속성을 공유하는 Numerics / PhysicsParams라는 두 가지 클래스가 있습니다. 그러므로 그것들은 추상 클래스 IParams에서 상속 받게합니다. 이 경우 순수 가상 일 수있는 방법이 전혀 없었습니다. 예를 들어 setParameter 메소드는 모든 서브 클래스에 대해 동일한 본문을 가져야합니다. 내가 가진 유일한 선택은 IParams의 소멸자를 순수한 가상으로 만드는 것이 었습니다.

struct IParams
{
    IParams(const ModelConfiguration& aModelConf);
    virtual ~IParams() = 0;

    void setParameter(const N_Configuration::Parameter& aParam);

    std::map<std::string, std::string> m_Parameters;
};

struct NumericsParams : IParams
{
    NumericsParams(const ModelConfiguration& aNumericsConf);
    virtual ~NumericsParams();

    double dt() const;
    double ti() const;
    double tf() const;
};

struct PhysicsParams : IParams
{
    PhysicsParams(const N_Configuration::ModelConfiguration& aPhysicsConf);
    virtual ~PhysicsParams();

    double g()     const; 
    double rho_i() const; 
    double rho_w() const; 
};

이미 구현되고 테스트 된 파생 클래스를 변경하지 않고 기본 클래스의 인스턴스화를 중지하려면 기본 클래스에서 순수한 가상 소멸자를 구현합니다.

여기서 가상 소멸자 가 필요할 때와 순수한 가상 소멸자 가 필요할 때 를 말하고 싶습니다.

class Base
{
public:
    Base();
    virtual ~Base() = 0; // Pure virtual, now no one can create the Base Object directly 
};

Base::Base() { cout << "Base Constructor" << endl; }
Base::~Base() { cout << "Base Destructor" << endl; }


class Derived : public Base
{
public:
    Derived();
    ~Derived();
};

Derived::Derived() { cout << "Derived Constructor" << endl; }
Derived::~Derived() {   cout << "Derived Destructor" << endl; }


int _tmain(int argc, _TCHAR* argv[])
{
    Base* pBase = new Derived();
    delete pBase;

    Base* pBase2 = new Base(); // Error 1   error C2259: 'Base' : cannot instantiate abstract class
}

1. 아무도 Base 클래스의 객체를 직접 만들 수 없도록하려면 순수한 가상 소멸자를 사용하십시오 virtual ~Base() = 0. 일반적으로 최소한 하나의 순수한 가상 기능이 필요 virtual ~Base() = 0합니다.

2. 위의 것이 필요하지 않은 경우에만 파생 클래스 객체의 안전한 파괴가 필요합니다.

   Base * pBase = new Derived (); pBase를 삭제하십시오. 순수한 가상 소멸자는 필요하지 않으며 가상 소멸자만이 작업을 수행합니다.

이 답변으로 가설을 세울 수 있으므로 명확성을 기하기 위해 더 간단하고 지구 설명에 이르기까지 설명하려고합니다.

객체 지향 디자인의 기본 관계는 IS-A와 HAS-A입니다. 나는 그것들을 만들지 않았다. 그것이 그들이 부르는 것입니다.

IS-A는 특정 개체가 클래스 계층에서 그 위에있는 클래스임을 식별합니다. 바나나 오브젝트는 과일 클래스의 서브 클래스 인 경우 과일 오브젝트입니다. 이것은 과일 클래스를 사용할 수있는 곳이면 어디서나 바나나를 사용할 수 있다는 것을 의미합니다. 그러나 그것은 반사적이지 않습니다. 특정 클래스가 필요한 경우 특정 클래스를 기본 클래스로 대체 할 수 없습니다.

Has-a는 객체가 복합 클래스의 일부이며 소유권 관계가 있음을 나타냅니다. 그것은 C ++에서 그것이 멤버 객체라는 것을 의미하며, 따라서 자신을 파괴하기 전에 그것을 처분하거나 소유권을 넘겨주는 소유 클래스에 있습니다.

이 두 개념은 c ++와 같은 다중 상속 모델보다 단일 상속 언어에서 구현하기가 쉽지만 규칙은 본질적으로 동일합니다. Fruit 클래스 포인터를 취하는 함수에 바나나 클래스 포인터를 전달하는 것과 같이 클래스 ID가 모호 할 때 복잡성이 발생합니다.

가상 기능은 첫째 런타임입니다. 다형성의 일부로, 실행중인 프로그램에서 호출 될 때 실행할 함수를 결정하는 데 사용됩니다.

virtual 키워드는 클래스 ID에 대한 모호성이있는 경우 특정 순서로 함수를 바인드하는 컴파일러 지시문입니다. 가상 함수는 항상 부모 클래스 (내가 아는 한)에 있으며 멤버 함수를 이름에 바인딩하는 것은 먼저 서브 클래스 함수와 부모 클래스 함수를 사용해야합니다.

Fruit 클래스에는 기본적으로 "NONE"을 반환하는 가상 함수 color ()가있을 수 있습니다. Banana 클래스 color () 함수는 "YELLOW"또는 "BROWN"을 반환합니다.

그러나 Fruit 포인터를 취하는 함수가 Banana 클래스에 color ()를 호출하면 어떤 color () 함수가 호출됩니까? 이 함수는 일반적으로 Fruit 객체에 대해 Fruit :: color ()를 호출합니다.

그것은 시간의 99 %가 의도 한 것이 아닐 것입니다. 그러나 Fruit :: color ()가 virtual로 선언 된 경우 호출시 올바른 color () 함수가 Fruit 포인터에 바인딩되므로 Banana : color ()가 객체에 대해 호출됩니다. 런타임은 포인터가 과일 클래스 정의에서 가상으로 표시 되었기 때문에 포인터가 가리키는 객체를 확인합니다.

이것은 서브 클래스에서 함수를 재정의하는 것과 다릅니다. 이 경우 Fruit 포인터는 Fruit :: color ()를 호출합니다.

이제 "순수 가상 기능"이라는 아이디어가 나옵니다. 순도는 그것과 관련이 없기 때문에 다소 불행한 문구입니다. 그것은 기본 클래스 메소드가 호출되지 않도록 의도되었음을 의미합니다. 실제로 순수한 가상 함수를 호출 할 수 없습니다. 그러나 여전히 정의되어 있어야합니다. 함수 서명이 존재해야합니다. 많은 코더가 완전성을 위해 빈 {{} 구현을 수행하지만 컴파일러는 내부적으로 생성합니다. 이 경우 포인터가 Fruit 일지라도 함수가 호출되면 color ()의 유일한 구현이므로 Banana :: color ()가 호출됩니다.

이제 퍼즐의 마지막 조각 : 생성자와 소멸자.

순수한 가상 생성자는 완전히 불법입니다. 그냥 나왔어

그러나 순수 가상 소멸자는 기본 클래스 인스턴스 생성을 금지하려는 경우 작동합니다. 기본 클래스의 소멸자가 순수 가상 인 경우 하위 클래스 만 인스턴스화 할 수 있습니다. 컨벤션은 0에 할당하는 것입니다.

 virtual ~Fruit() = 0;  // pure virtual 
 Fruit::~Fruit(){}      // destructor implementation

이 경우 구현을 작성해야합니다. 컴파일러는 이것이 당신이하고있는 일임을 알고 올바르게 수행하는지 확인하거나 컴파일 해야하는 모든 기능에 연결할 수 없다고 강력하게 불평합니다. 클래스 계층을 모델링하는 방법에 대한 올바른 길을 찾지 못하면 오류가 혼동 될 수 있습니다.

따라서이 경우 Fruit 인스턴스를 만들 수 없지만 Banana 인스턴스를 만들 수 있습니다.

Banana의 인스턴스를 가리키는 Fruit 포인터를 삭제하면 먼저 Banana :: ~ Banana ()를 호출 한 다음 항상 Fuit :: ~ Fruit ()을 호출합니다. 서브 클래스 소멸자를 호출 할 때는 기본 클래스 소멸자를 따라야합니다.

나쁜 모델입니까? 디자인 단계에서는 더 복잡하지만, 정확한 링크가 런타임에 수행되고 서브 클래스 기능이 정확히 어떤 서브 클래스에 액세스되는지 모호한 곳에서 수행되도록 보장 할 수 있습니다.

C ++을 작성하여 일반적인 포인터 나 모호한 포인터가없는 정확한 클래스 포인터 만 전달하면 가상 함수가 실제로 필요하지 않습니다. 그러나 (Apple Banana Orange ==> Fruit에서와 같이) 유형의 런타임 유연성이 필요한 경우 중복 코드가 적어 기능이 더 쉽고 다양합니다. 더 이상 각 과일 유형에 대해 함수를 작성할 필요가 없으며 모든 과일이 고유 한 올바른 함수로 color ()에 응답한다는 것을 알고 있습니다.

이 긴 설명이 혼란을 일으키는 것이 아니라 개념을 강화시키기를 바랍니다. 거기에는 볼만한 좋은 예가 많이 있으며, 충분히 살펴보고 실제로 실행하고 엉망으로 만들면 얻을 수 있습니다.

이것은 10 년 전의 주제입니다.) "Effective C ++"책에서 항목 # 7의 마지막 5 개 단락을 자세히 읽으십시오. "클래스에 순수한 가상 소멸자를 제공하는 것이 편리 할 수 ​​있습니다 ...."

당신은 예를 물었고 다음은 순수한 가상 소멸자에 대한 이유를 제공한다고 생각합니다. 이것이 좋은 이유 인지에 대한 답장을 기대합니다 ...

나는 누군가가 던질 수 없도록하려면 error_base유형을하지만, 예외 유형 error_oh_shucks과 error_oh_blast동일한 기능을 가지고 있고이 두 번 쓰고 싶지 않습니다. pImpl의 복잡성은 std::string내 고객에게 노출되는 것을 피하기 위해 필요 하며이를 사용 std::auto_ptr하려면 복사 생성자 가 필요합니다.

공개 헤더에는 내 라이브러리에서 발생하는 다양한 유형의 예외를 구별하기 위해 클라이언트가 사용할 수있는 예외 사양이 포함되어 있습니다.

// error.h

#include <exception>
#include <memory>

class exception_string;

class error_base : public std::exception {
 public:
  error_base(const char* error_message);
  error_base(const error_base& other);
  virtual ~error_base() = 0; // Not directly usable

  virtual const char* what() const;
 private:
  std::auto_ptr<exception_string> error_message_;
};

template<class error_type>
class error : public error_base {
 public:
   error(const char* error_message) : error_base(error_message) {}
   error(const error& other) : error_base(other) {}
   ~error() {}
};

// Neither should these classes be usable
class error_oh_shucks { virtual ~error_oh_shucks() = 0; }
class error_oh_blast { virtual ~error_oh_blast() = 0; }

공유 구현은 다음과 같습니다.

// error.cpp

#include "error.h"
#include "exception_string.h"

error_base::error_base(const char* error_message)
  : error_message_(new exception_string(error_message)) {}

error_base::error_base(const error_base& other)
  : error_message_(new exception_string(other.error_message_->get())) {}

error_base::~error_base() {}

const char* error_base::what() const {
  return error_message_->get();
}

private로 유지되는 exception_string 클래스는 내 공용 인터페이스에서 std :: string을 숨 깁니다.

// exception_string.h

#include <string>

class exception_string {
 public:
  exception_string(const char* message) : message_(message) {}

  const char* get() const { return message_.c_str(); }
 private:
  std::string message_;
};

내 코드는 다음과 같이 오류를 발생시킵니다.

#include "error.h"

throw error<error_oh_shucks>("That didn't work");

템플릿을 사용 error하는 것은 약간 무의미합니다. 클라이언트가 다음과 같이 오류를 포착하도록 요구하면서 약간의 코드를 절약합니다.

// client.cpp

#include <error.h>

try {
} catch (const error<error_oh_shucks>&) {
} catch (const error<error_oh_blast>&) {
}

어쩌면 다른 답변에서 실제로 볼 수없는 순수한 가상 소멸자의 또 다른 실제 사용 사례 가있을 수 있습니다 :)

처음에는 나는 명백한 대답에 완전히 동의합니다. 순수한 가상 소멸자를 금지하면 언어 사양에 추가 규칙이 필요하기 때문입니다. 그러나 여전히 Mark가 요구하는 유스 케이스는 아닙니다. :)

먼저 이것을 상상해보십시오.

class Printable {
  virtual void print() const = 0;
  // virtual destructor should be here, but not to confuse with another problem
};

그리고 다음과 같은 것 :

class Printer {
  void queDocument(unique_ptr<Printable> doc);
  void printAll();
};

간단하게-인터페이스 Printable와이 인터페이스로 무엇이든 보유하는 일부 "컨테이너"가 있습니다. 여기서 print()메소드가 순수한 가상 인 이유 가 분명하다고 생각합니다 . 본문이있을 수 있지만 기본 구현이없는 경우 순수한 가상은 이상적인 "구현"입니다 (= "자손 클래스에서 제공해야 함").

이제는 인쇄용이 아니라 파괴 용이라는 점을 제외하고는 정확히 동일하게 상상하십시오.

class Destroyable {
  virtual ~Destroyable() = 0;
};

또한 비슷한 컨테이너가있을 수 있습니다.

class PostponedDestructor {
  // Queues an object to be destroyed later.
  void queObjectForDestruction(unique_ptr<Destroyable> obj);
  // Destroys all already queued objects.
  void destroyAll();
};

실제 응용 프로그램에서 단순화 된 유스 케이스입니다. 여기서 유일한 차이점은 "normal"대신 "special"메소드 (소멸자)가 사용되었다는 것입니다 print(). 그러나 순수한 가상 인 이유는 여전히 동일합니다. 메소드의 기본 코드는 없습니다. 약간의 혼란은 효과적으로 소멸자가 있어야하고 컴파일러가 실제로 빈 코드를 생성한다는 사실입니다. 그러나 프로그래머의 관점에서 순수한 가상 성은 여전히 ​​다음과 같은 의미를 가지고 있습니다. "기본 코드가 없으므로 파생 클래스에서 제공해야합니다."

순수한 가상이 실제로 균일하게 작동한다는 소멸자에게도 더 많은 설명이 있습니다.

1) 파생 클래스에서 정리를 요구하려는 경우. 이것은 드물다.

2) 아니요, 그러나 가상적이기를 원합니다.

소멸자를 가상으로 만들지 않으면 컴파일러는 기본 클래스의 내용 만 파괴하고 n 파생 클래스는 변경되지 않고 bacuse 컴파일러는 다른 소멸자를 호출하지 않습니다. 기본 클래스를 제외한 클래스.