It is not true that vtable pointers in objects are always the most efficient. My compiler for another language used to use in-object pointers for similar reasons but no longer does: instead it uses a separate data structure which maps the object address to the required meta-data: in my system this happens to be shape … Read more
The comment is not correct. Both: virtual ~A() = default; and virtual ~A() {} are user declared. And the implicit move members are inhibited if the destructor is user declared. [dcl.fct.def.default]/p4 discusses user-declared and user-provided special members: A special member function is user-provided if it is user-declared and not explicitly defaulted or deleted on its … Read more
Short Answer: No. Long Answer: It is not the base class or the number of ancestors a class has in its hierarchy that affects it speed. The only thing is the cost of a method call. A non virtual method call has a cost (but can be inlined) A virtual method call has a slightly … Read more
Those are the offset-to-top (needed for multiple inheritence) and typeinfo (RTTI) pointers. From the Itanium ABI (you are not using the Itanium compiler, but their description of this is really good): The offset to top holds the displacement to the top of the object from the location within the object of the virtual table pointer … Read more
The classic is a pure virtual destructor: class abstract { public: virtual ~abstract() = 0; }; abstract::~abstract() {} You make it pure because there’s nothing else to make so, and you want the class to be abstract, but you have to provide an implementation nevertheless, because the derived classes’ destructors call yours explicitly. Yeah, I … Read more
There are good reasons for controlling which methods are virtual beyond performance. While I don’t actually make most of my methods final in Java, I probably should… unless a method is designed to be overridden, it probably shouldn’t be virtual IMO. Designing for inheritance can be tricky – in particular it means you need to … Read more
So basically if in your ancestor class you want a certain behaviour for a method. If your descendent uses the same method but has a different implementation you can override it, If it has a virtual keyword. using System; class TestClass { public class Dimensions { public const double pi = Math.PI; protected double x, … Read more
You do get the surprising result that if you have a child, you can’t call foo, but you can cast it to a base and then call foo. child *c = new child(); c->foo; // compile error (can’t access private member) static_cast<base *>(c)->foo(); // this is fine, but still calls the implementation in child I … Read more
No, because it doesn’t make any sense in C++. Virtual functions are invoked when you have a pointer/reference to an instance of a class. Static functions aren’t tied to a particular instance, they’re tied to a class. C++ doesn’t have pointers-to-class, so there is no scenario in which you could invoke a static function virtually.
Yes, you can definitely use = default for such destructors. Especially if you were just going to replace it with {}. I think the = default one is nicer, because it’s more explicit, so it immediately catches the eye and leaves no room for doubt. However, here are a couple of notes to take into … Read more