destructor

scalar deleting destructor issue

由 主宰稳场 提交于 2019-12-04 11:54:00
问题 I can't figure out why I get error for the code below. The instances of object A will be pushed into a vector ( vectorA.push_back(A a) ) continuously. So sometimes, vectorA needs to be reallocated; the destructor will be called, which is where the destructor of A gets called, then the error message appears. class A { long filePos; union { Recording* recording; UINT64 timeStamp; }; public: inline A(long fpos, UINT64 ts) : filePos(fpos), timeStamp(ts) {} ~A() { if (getDetailedType() ==

exit(0) vs return 0

由 拥有回忆 提交于 2019-12-04 10:37:03
问题 When exit(0) is used to exit from program, destructors for locally scoped non-static objects are not called. But destructors are called if return 0 is used.Note that static objects will be cleaned up even if we call exit(). There should be some reason behind this logic. i just want to know what it is? Thank you. 回答1: In the case of exit( 0 ) , you're calling a function. You don't expect the destructors of local variables to be called if you're calling a function. And the compiler doesn't know

Clearing controls from FlowLayoutPanel not calling destructors?

由 落爺英雄遲暮 提交于 2019-12-04 09:08:49
Sorry if I'm missing something obvious, but I'm trying to clear the controls (a series of user controls) from a FlowLayoutPanel - (panelName).Controls.Clear();. Unfortunately this doesn't seem to be calling the destructors for the objects on the panel - the User Objects column in the task manager just keeps going up and up, until it hits 10,000 and throws an excecption. Does anyone know what I'm missing here? Not a solution, but a workaround - the objects do seem to be destroyed by this (rough, from memory) code: while(FlowLayoutPanel.Controls.Count > 0) FlowLayoutPanel.Controls.Remove(0);

Exception in Destructor C++

由 孤街醉人 提交于 2019-12-04 08:48:42
问题 I am well aware of the fact that one should not throw any exception in destructor. But as a part of making my grip on this concept,I coded this example :- #include <iostream> using namespace std; class A { private: int i; public: A() { i = 10; } ~A() { throw 30; } }; int main(){ try{ A(); throw 10; } catch (int i){ cout << i << endl; cout << "exception caught" << endl; } } As per my understanding, this program should be terminated by calling std::terminate() as there will be two exceptions at

Locking a mutex in a destructor in C++11

由 拜拜、爱过 提交于 2019-12-04 08:41:15
问题 I have some code which need to be thread safe and exception safe. The code below is a very simplified version of my problem : #include <mutex> #include <thread> std::mutex mutex; int n=0; class Counter{ public: Counter(){ std::lock_guard<std::mutex>guard(mutex); n++;} ~Counter(){ std::lock_guard<std::mutex>guard(mutex);//How can I protect here the underlying code to mutex.lock() ? n--;} }; void doSomething(){ Counter counter; //Here I could do something meaningful } int

Destructors not called when native (C++) exception propagates to CLR component

由 ≯℡__Kan透↙ 提交于 2019-12-04 08:34:23
问题 We have a large body of native C++ code, compliled into DLLs. Then we have a couple of dlls containing C++/CLI proxy code to wrap the C++ interfaces. On top of that we have C# code calling into the C++/CLI wrappers. Standard stuff, so far. But we have a lot of cases where native C++ exceptions are allowed to propagate to the .Net world and we rely on .Net's ability to wrap these as System.Exception objects and for the most part this works fine. However we have been finding that destructors of

How to use __del__ in a reliable way?

由 北城余情 提交于 2019-12-04 06:40:06
I have learned that python does not guarantee that __del__ is called whenever an object is deleted. In other words, del x does not necessarily invoke its destructor x.__del__() . If I want to ensure proper object cleanup, I should use a context manager (in a with statement). I know it's stupid, but for a couple of reasons (please don't ask why) I am tied to a system with Python 2.4; therefore context managers are out of question (they were introduced in Python 2.5) So I need a an alternative solution, and hence my question: are there best practices that would help me to use __del__ reliably? I

Stack unwinding in C++ when using Lua

由 徘徊边缘 提交于 2019-12-04 06:18:09
I recently stumbled into this this C++/Lua error int function_for_lua( lua_State* L ) { std::string s("Trouble coming!"); /* ... */ return luaL_error(L,"something went wrong"); } The error is that luaL_error use longjmp , so the stack is never unwound and s is never destructed, leaking memory. There are a few more Lua API's that fail to unwind the stack. One obvious solution is to compile Lua in C++ mode with exceptions. I, however, cannot as Luabind needs the standard C ABI. My current thought is to write my own functions that mimic the troublesome parts of the Lua API: // just a heads up

How do virtual destructors work?

由 南笙酒味 提交于 2019-12-04 05:58:30
Few hours back I was fiddling with a Memory Leak issue and it turned out that I really got some basic stuff about virtual destructors wrong! Let me put explain my class design. class Base { virtual push_elements() {} }; class Derived:public Base { vector<int> x; public: void push_elements(){ for(int i=0;i <5;i++) x.push_back(i); } }; void main() { Base* b = new Derived(); b->push_elements(); delete b; } The bounds checker tool reported a memory leak in the derived class vector. And I figured out that the destructor is not virtual and the derived class destructor is not called. And it

static destructor

由 牧云@^-^@ 提交于 2019-12-04 03:57:22
Suppose I have: void foo() { static Bar bar; } Does c++ guarantee me that Bar::Bar() is called on bar, and Bar::~Bar() is never called on bar? (Until after main exits). Thanks! Yes. The first time foo() is called, Bar bar will be constructed. It will then be available until main() finishes, after which point it will be destructed. It's essentially: static Bar *bar = 0; if (!bar) { bar = new Bar; // not "real", of course void delete_bar(void) { delete bar; } atexit(delete_bar); } Note I said "essentially"; this probably isn't what actually happens (though I don't think it's too far off). 3.7.1
订阅 destructor