destructor

From the python docs : It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits. Why not? What problems would occur if this guarantee were made? I'm not convinced by the previous answers here. Firstly note that the example given does not prevent __del__ methods being called during exit. In fact, the current CPythons will call the __del__ method given, twice in the case of Python 2.7 and once in the case of Python 3.4. So this can't be the "killer example" which shows why the guarantee is not made. I think the statement in the docs is not

The following code prints one,two,three. Is that desired and true for all C++ compilers? class Foo { const char* m_name; public: Foo(const char* name) : m_name(name) {} ~Foo() { printf("%s\n", m_name); } }; void main() { Foo foo("three"); Foo("one"); // un-named object printf("two\n"); } A temporary variable lives until the end of the full expression it was created in. Yours ends at the semicolon. This is in 12.2/3: Temporary objects are destroyed as the last step in evaluating the full-expression (1.9) that (lexically) contains the point where they were created. Your behavior is guaranteed.

I am fairly new to learning C# (from Java & C++ background) and I have a question about manual garbage disposal: is it even possible to manually destroy an object in C#? I know about the IDisposable interface, but suppose I'm dealing with a class which I didn't write and it doesn't implement it? It wouldn't have a .Dispose() method, so that and using { } is out, and .Finalize is always either protected or private so that's not an option either. (I am just trying to learn what is possible in C# in this case. I suppose if all else fails I could inherit the hypothetical ImNotDisposable class so

For example: int main() { Foo *leedle = new Foo(); return 0; } class Foo { private: somePointer* bar; public: Foo(); ~Foo(); }; Foo::~Foo() { delete bar; } Would the destructor be implicitly called by the compiler or would there be a memory leak? I'm new to dynamic memory, so if this isn't a usable test case, I'm sorry. Yes, automatic variables will be destroyed at the end of the enclosing code block. But keep reading. Your question title asks if a destructor will be called when the variable goes out of scope. Presumably what you meant to ask was: will Foo's destructor be called at the end of

I am studying how garbage collector works in c#. I am confused over the use of Destructor , Dispose and Finalize methods. As per my research and understandings, having a Destructor method within my class will tell the garbage collector to perform the garbage collection in the way mentioned in the destructor method which cannot be called explicitly on the instances of the class. The Dispose method is meant to provide the user to control the garbage collection. The Finalize method frees the resources used by the class, but not the object itself. I am not sure if I understand it the right way.

What is the difference, if there is one, between a destructor and a Finalize method in a class? I recently discovered that Visual Studio 2008 considers a destructor synonymous with a Finalize method, meaning that Visual Studio won't let you simultaneously define both methods in a class. For example, the following code fragment: class TestFinalize { ~TestFinalize() { Finalize(); } public bool Finalize() { return true; } } Gives the following error on the call to Finalize in the destructor: The call is ambiguous between the following methods or properties: 'TestFinalize.~TestFinalize()' and

Suppose we have a (toy) C++ class such as the following: class Foo { public: Foo(); private: int t; }; Since no destructor is defined, a C++ compiler should create one automatically for class Foo . If the destructor does not need to clean up any dynamically allocated memory (that is, we could reasonably rely on the destructor the compiler gives us), will defining an empty destructor, ie. Foo::~Foo() { } do the same thing as the compiler-generated one? What about an empty constructor -- that is, Foo::Foo() { } ? If there are differences, where do they exist? If not, is one method preferred over