virtual-destructor | 易学教程

Correct way to inherit from a virtual class with non-virtual parent

阅读更多关于 Correct way to inherit from a virtual class with non-virtual parent

问题 I've written this test code that uses three types: struct One is a normal type with no virtual members, struct Two : One has a pure virtual function and a virtual destructor, and struct Three : Two implements Two 's interface. #include <iostream> struct One { ~One() { std::cout << "~One()\n"; } }; struct Two : One { virtual ~Two() { std::cout << "~Two()\n"; } virtual void test() = 0; }; struct Three : Two { virtual ~Three() { std::cout << "~Three()\n"; } virtual void test() { std::cout <<

order of destruction using virtual

阅读更多关于 order of destruction using virtual

问题 Can some one please help what the order of destruction is when I am using virtual functions. Does it start with the base class and then derived class? 回答1: Since I don't see how virtual function change any objects' destruction order, I assume you're referring to the order of destruction for base classes and data members in a virtual inheritance scenario. Sub-objects are constructed base classes are constructed from most base to most derived ; multiple base classes are constructed in the order

Override identifier after destructor in C++11

阅读更多关于 Override identifier after destructor in C++11

问题 Does the override identifier after virtual destructor declaration have any special meaning? class Base { public: virtual ~Base() {} virtual int Method() const {} }; class Derived : public Base { public: virtual ~Derived() override {} virtual int Method() override // error: marked override, but does not override - missing const {} }; Using override identifier on virtual method is useful as check: compiler will report error when the Base virtual method is actualy not overriden. Does override on

CRT virtual destructor

阅读更多关于 CRT virtual destructor

问题 I ran into a heap corruption today caused by different CRT settings (MTd MDd) in my dll and my actual project. What I found strange is that the application only crashed when I set the destructor in the dll to be virtual. Is there an easy explanation for that? I get that I can't free memory that's not on my heap, but where exactly is the difference when I define the destructor as non-virtual. Some Code just to make it a little clearer The DLL #pragma once class CTestClass { public: _declspec

Clang complains “cannot override a deleted function” while no function is deleted

阅读更多关于 Clang complains “cannot override a deleted function” while no function is deleted

问题 In the following simple code fragment: #include <cstddef> struct B { virtual ~B() = default; static void operator delete(void *, int); static void * operator new(size_t, int); }; struct C : B { virtual ~C() = default; }; clang 3.7 complains that "non-deleted function '~C' cannot override a deleted function": http://goo.gl/Ax6oth Neither Visual Studio nor GCC report an error in this code. Is it a clang defect or what? 回答1: static void operator delete(void *, int); No, it's static void operator

How to declare the virtual destructor without breaking move and copy constructors

阅读更多关于 How to declare the virtual destructor without breaking move and copy constructors

问题 When adding a user defined default virtual destructor to a class like this.. class Foo { public: Foo(); virtual ~Foo() = default; }; .. It has the side effects of preventing auto generation of move constructors. Also auto generation of copy constructors is deprecated. A recommended way is to user define all constructors like this.. class Foo { public: Foo(); virtual ~Foo() = default; Foo(const Foo& /* other */) = default; Foo&operator=(const Foo& /* other */) = default; Foo(Foo&& /* other */)

Does “delete” work properly with polymorphism? [duplicate]

阅读更多关于 Does “delete” work properly with polymorphism? [duplicate]

This question already has an answer here: Virtual destructor and undefined behavior 4 answers BaseClass * p = new DerivedClass(); delete p; I know the 2nd line will call the destructor of the base class if it doesn't have a virtual destructor and that of the derived class if it does but will delete properly free the memory (let's say BaseClass 's object takes up 8 bytes of space and DerivedClass 's one 12 - will it free 8 or 12 bytes) and get rid of the object in either case? Well in the case that it has a virtual destructor, of course the object will be destroyed and the memory deallocated as

C++11 interface pure virtual destructor

阅读更多关于 C++11 interface pure virtual destructor

UPD . There is a mark that it is a duplicate of this question . But in that question OP asks HOW to use default to define pure virtual destructor. This question is about what the difference . In C++ (latest standard if possible) what the real difference between defining pure virtual destructor with empty body implementation and just a empty body (or default)? Variant 1: class I1 { public: virtual ~I1() {} }; Variant 2.1: class I21 { public: virtual ~I21() = 0; }; I21::~I21() {} Variant 2.2: class I22 { public: virtual ~I22() = 0; }; I22::~I22() = default; Update I found at least 1 difference

Does a default virtual destructor prevent compiler-generated move operations?

阅读更多关于 Does a default virtual destructor prevent compiler-generated move operations?

问题 Inspired by the post Why does destructor disable generation of implicit move methods? , I was wondering if the same is true for the default virtual destructor, e.g. class WidgetBase // Base class of all widgets { public: virtual ~WidgetBase() = default; // ... }; As the class is intended to be a base class of a widget hierarchy I have to define its destructor virtual to avoid memory leaks and undefined behavior when working with base class pointers. On the other hand I don't want to prevent

How to declare the virtual destructor without breaking move and copy constructors

阅读更多关于 How to declare the virtual destructor without breaking move and copy constructors

When adding a user defined default virtual destructor to a class like this.. class Foo { public: Foo(); virtual ~Foo() = default; }; .. It has the side effects of preventing auto generation of move constructors. Also auto generation of copy constructors is deprecated. A recommended way is to user define all constructors like this.. class Foo { public: Foo(); virtual ~Foo() = default; Foo(const Foo& /* other */) = default; Foo&operator=(const Foo& /* other */) = default; Foo(Foo&& /* other */) = default; Foo&operator=(Foo&& /* other */) = default; }; However, this is super verbose and