destructor

how much does the default destructor do

蹲街弑〆低调 提交于 2019-12-03 11:57:46
Does the default destructor in C++ classes automatically delete members that are not explicitly allocated in code? For example: class C { public: C() {} int arr[100]; }; int main(void) { C* myC = new C(); delete myC; return 0; } Does delete myC deallocate myC's arr automatically? Or do I need to write C's destructor to do this explicitly? The constructor (in the absence of any ctor-initializer-list ) calls the default constructor for each subobject. Since you have no base classes and your member variables are primitive types, it will do nothing at all. Same with the destructor. Yours is

Should destructors be threadsafe?

你离开我真会死。 提交于 2019-12-03 11:27:37
I was going through a legacy code and found the following snippet: MyClass::~MyClass() { EnterCriticalSection(&cs); //Access Data Members, **NO Global** members are being accessed here LeaveCriticalSection(&cs); } I am wondering will it help by any chance to guard the destructor ? Consider a scenario : 1. Thread1 - About to execute any of the member function which uses critical section 2. Thread2- About to execute destructor. If the order of execution is 1=>2 then it might work. But what if the order is reversed ? Is it a design issue ? The destructor should not be called when the object is in

Inheritance and Destructors in C#

拟墨画扇 提交于 2019-12-03 11:05:53
According to this , it states that Destructors cannot be inherited or overloaded. In my case, for all subclasses, the destructors will be identical. Is this pretty much telling me that I must define the same destructor in each sub class. There is no way that I can declare the destructor in the base class and have the handle the destruction? Say I have something like this: class A { ~A() { SomethingA(); } } class B : A { } B b = new B(); When B is destroyed, its destructor wont be called? Eric Lippert According to this, it states that Destructors cannot be inherited or overloaded. Correct.

How to delete an object of a polymorphic class type that has no virtual destructor

女生的网名这么多〃 提交于 2019-12-03 10:55:41
I am getting the following error when I try to compile some code from a Third-party SDK. *Description Resource Path Location Type deleting object of polymorphic class type ‘Vendor_sys::VendorCode’ which has non-virtual destructor might cause undefined behaviour [-Werror=delete-non-virtual-dtor] PnServer.cpp /PCounter line 467 C/C++ Problem* I do not know if its possible to satisfy this condition with only partial knowledge of the Vendor's SDK, where most of the heavy lifting is done in a dll or library object. My build environment is Eclipse Juno with gpp. I searched in Google for the error

Default constructor/destructor outside the class?

夙愿已清 提交于 2019-12-03 10:51:08
Is the following legal according to the C++11 standard ( = default outside the definition of the class) ? // In header file class Test { public: Test(); ~Test(); }; // In cpp file Test::Test() = default; Test::~Test() = default; Yes, a special member function can be default-defined out-of-line in a .cpp file. Realize that by doing so, some of the properties of an inline-defaulted function will not apply to your class. For example, if your copy constructor is default-defined out-of-line, your class will not be considered trivially copyable (which also disqualifies it from being recognized as a

Undefined reference to 'operator delete(void*)'

[亡魂溺海] 提交于 2019-12-03 10:46:00
I'm new to C++ programming, but have been working in C and Java for a long time. I'm trying to do an interface-like hierarchy in some serial protocol I'm working on, and keep getting the error: Undefined reference to 'operator delete(void*)' The (simplified) code follows below: PacketWriter.h: class PacketWriter { public: virtual ~PacketWriter() {} virtual uint8_t nextByte() = 0; } StringWriter.h: class StringWriter : public PacketWriter { public: StringWriter(const char* message); virtual uint8_t nextByte(); } The constructor and nextByte functions are implemented in StringWriter.cpp, but

Catching exceptions in destructors

时光总嘲笑我的痴心妄想 提交于 2019-12-03 10:33:12
Is it possible to make a destructor catch exceptions and then re-throw them? If so, how would I do that, since there isn't a clear place for a try statement? Basically, I want to ideally do: CMyObject::~CMyObject() { catch(...) // Catch without a try. Possible? { LogSomeInfo(); throw; // re-throw the same exception } // Normal Destructor operations } Background I have a large, complex application that is throwing an unhandled exception somewhere. I don't have easy access to main or the top level message-pump or anything similar, so there's no easy place to catch all unhandled exceptions. I

Excel VBA object constructor and destructor

Deadly 提交于 2019-12-03 10:31:52
I need to make some custom objects in VBA that will need to reference each other and I have a some issues. First - how do object constructors work in VBA? Are there constructors? Second - are there destructors? How does VBA handle the end of the object lifecycle? If I have an object that references others (and this is their only reference), then can I set it to Nothing and be done with it or could that produce memory leaks? This quasi-OO stuff is just a little bit irritating. VBA supports Class Modules. They have a Class_Initialize event that is the constructor and a Class_Terminate that is

Can `weakref` callbacks replace `__del__`?

陌路散爱 提交于 2019-12-03 10:13:17
Is there any obstacle that prevents weakref from doing everything that __del__ does but with much stronger guarantees (e.g., finalize guarantees that the call will be made before the interpreter exits, and the order of calls is well-defined, etc.)? It seems that in the distant past it was thought that weakref would eventually lead to the removal of __del__ from the language. What prevented this from happening? There seems to be few use cases for __del__ , and all the ones I'm aware of seem to work at least as well (and usually much better) with weakref callbacks or weakref.finalize . Update:

Self destruction: this->MyClass::~MyClass() vs. this->~MyClass()

一笑奈何 提交于 2019-12-03 09:27:35
In my quest to learn C++ I stumbled across the article Writing Copy Constructors and Assignment Operators which proposes a mechanism to avoid code duplication across copy constructors and assignment operators. To summarise/duplicate the content of that link, the proposed mechanism is: struct UtilityClass { ... UtilityClass(UtilityClass const &rhs) : data_(new int(*rhs_.data_)) { // nothing left to do here } UtilityClass &operator=(UtilityClass const &rhs) { // // Leaves all the work to the copy constructor. // if(this != &rhs) { // deconstruct myself this->UtilityClass::~UtilityClass(); //