Terminology, terminology… OK, what do we mean by “Foo is inherited”? We mean that if objects of class A have Foo in its interface, then objects of class B which is a subclass of A also have Foo in its interface. Constructors aren’t a part of objects’ interface. They belong directly to classes. Classes A … Read more
It’s undefined behavior, so anything can happen. Quote from the standard [expr.delete]: In the first alternative (delete object), if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static … Read more
You cannot create weak references to method objects. Method objects are short lived; they are created on the fly as you access the name on the instance. See the descriptor howto how that works. When you access a method name, a new method object is created for you, and when you then add that method … Read more
I simply do not understand what “depends on the side effects” means. It means that it depends on something the destructor is doing. In your example, modifying *p or not modifying it. You have that dependency in your code, as the output would differ if the dctor wouldn’t get called. In your current code, the … Read more
No, most destructors are not run on exit(). C++98 ยง18.3/8 discusses this. Essentially, when exit is called static objects are destroyed, atexit handlers are executed, open C streams are flushed and closed, and files created by tmpfile are removed. Local automatic objects are not destroyed. I.e., no stack unwinding. Calling abort lets even less happen: … Read more
Are there any other circumstances where they[destructors] will not be called? Long jumps: these interfere with the natural stack unwinding process and often lead to undefined behavior in C++. Premature exits (you already pointed these out, though it’s worth noting that throwing while already stack unwinding as a result of an exception being thrown leads … Read more
If the lifetime ends before the destructor starts, doesn’t that mean accessing members in the destructor is undefined behavior? Hopefully not: From N3242 Construction and destruction [class.cdtor] /3 To form a pointer to (or access the value of) a direct non-static member of an object obj, the construction of obj shall have started and its … Read more
“The Rule of Zero” is in fact about something else than what special member functions are generated and when. It is about a certain attitude to class design. It encourages you to answer a question: Does my class manage resources? If so, each resource should be moved to its dedicated class, so that your classes … Read more
Your class A has several issues: Your assignment operator don’t handle self assignment and leak: A& A::operator=(const A& a) { std::cout<<“overload operator=\n”; if (this != &a) { p = a.p; delete[] s; s = new char[strlen(a.s) + 1]; strcpy(s, a.s); } return *this; } Your move doesn’t move but copy: A::A(A&& a) : p(a.p), s(a.s) … Read more
You don’t manually destroy .Net objects. That’s what being a managed environment is all about. In fact, if the object is actually reachable, meaning you have a reference you can use to tell the GC which object you want to destroy, collecting that object will be impossible. The GC will never collect any object that’s … Read more