destructor

Earlier today I asked this question about the __del__() method of an object which uses an imported module. The problem was that __del__() wants to make use of the module os , but sometimes (not always) the module has already been deleted. I was told that when a Python program terminates, the order in which objects and modules are deleted can be random, and is undefined. However, for my application, I really need to make sure that an object (instance of a class I created) gets deleted before the module (in which the object is instantiated) gets deleted. Is there a way of doing this? As we told

In my WPF-application, I call new windows in the following way: _newWin = new WinWorkers_AddWorker(); _newWin.WindowState = this.WindowState; _newWin.Show(); Where _newWin is a private Window object . My question is should I assign a null value to _newWin after I call _newWin.Show() ? Will this decrease memory consumption because garbage collector / destructor will clean the null value objects earlier? Thanks. It's generally irrelevant to set a value to null. It's very rarely useful. It's occasionally harmful. Let's consider first the simplest case: private void DoStuff() { var newWin = new

I have a managed object in a c# dll that maintains an anonymous integer handle to an unmanaged object in a c++ dll. Inside the c++ dll, the anonymous integer is used in an std::map to retrieve an unmanaged c++ object. Through this mechanism, I can maintain a loose association between a managed and unmanaged object using an anonymous integer handle. In the finalize method (destructor) of the managed object I have a call into the unmanaged dll to delete the unmanaged object. All is well as the c# program runs, but I have a problem when the program exits. Becuase I have no control on the order of

I have read in C++ : The Complete Reference book the following Even though objects are passed to functions by means of the normal call-by-value parameter passing mechanism, which, in theory, protects and insulates the calling argument, it is still possible for a side effect to occur that may affect, or even damage, the object used as an argument. For example, if an object used as an argument allocates memory and frees that memory when it is destroyed, then its local copy inside the function will free the same memory when its destructor is called. This will leave the original object damaged and

Do you think it's a good idea? Let's say you have an application component that is used by other components to retrieve / update data in the db. It's basically a class with get(), set(), update() methods. Would it be a good idea for that component to update (or set) data only in it's properties when called, and on __destruct to update the db as well? Or should it directly update the db on each set/ update call ? Updating the database on object destruction smells to me a little bit like a software side effect . That is, an action that takes place in an unexpected and somewhat non-explicit place

I have such code #include <cstdlib> class Foo { int m_data; public : Foo() : m_data(0) { } /*~Foo() { }*/ static void* operator new[](const size_t size) { return malloc(size); } static void operator delete[](void* data) { free(data); } }; int main() { Foo* objects = new Foo[5]; delete [] objects; } In this case I receive value of size in operator new overloading as 20 bytes as I wanted ( sizeof(int) * 5 ). But if I uncomment the destructor I get size as 24 bytes. Yeah, I now that these extra bytes is used to store the size of allocated memory and equals to sizeof(size_t) . I can't understand