java override – strict on declared parameter types

Best practice – use @Override on the overriding method to request “approval” by the compiler. You will realize that is concise –

Rule 1: “return type of the overriding method can (but not c++ [1]) be a subclass of the return type of the overridden method, but the argument types must match exactly”

So almost all discrepancies between parent/child parameter types (like int vs long) will be compiled as overloads. The only exception I know is — overriding method can remove “” from List as the parameter type.

There could be other subtle rules when we consider generics, but in the world without parameterized method signatures, the above Rule 1 is clean and simple.

[[ARM]] P212 explains the Multiple-inheritance would be problematic if this were allowed.

c++method default arg isn’t saved]vtable #Ashish

Ashish said he was asked the same question in multiple c++ interviews. The default param value is “declared” in base class and/or derived class and isn’t saved in the vtable. It’s basically resolved statically, at compile time.

If you use a pointer to Base to invoke the virtual method, then the Base default value applies unconditionally, even though the subclass method is chosen at run time, via the vtable.

delete base class ptr,with non-virtual dtor#based dtor runs!

This correct code produces ” ~B ~A” i.e. reverse construction sequence. But what if “virtual” removed?

I said it’s undefined behavior, but what if we know it does do something?

I correctly predicted “~A”, tested in minGw.

class A{
public: virtual ~A(){ cout<<" ~ A"<<endl; }
class B: public A{
public: ~B(){ cout<<" ~ B "; }
int main(){
A * p = new B;
delete p;

"new virtual" modifiers in c#

Unlike java and c++, c# offers new-virtual, which marks a virtual method hiding a base-class virtual method.

* When used in an interface, you must omit the “virtual” since it’s implicit
* When used in a class C, you must spell out “new virtual”. There must be such a Virtual method in the base class B, and there should be a grand-child class D that Overrides this method. P75 [[c# precisely]] illustrates this BCD scenario.

In c#, “override” scares “new” as a method modifier, otherwise “new” plays happily with all other method modifiers —
– new virtual
– new abstract
– new static
– new (nothing) — simple, non-virtual method hiding

template specialization ^ virtual function

To achieve polymorphism, template specialization is an alternative to virtual functions. The way a “behavior” is chosen for a given type is by compile time template instantiation.

In contrast, virtual functions (including essentially all java non-static methods) use run time binding and require additional run time cost and per-instance memory cost –vptr.

In efficiency-sensitive and latency-sensitive apps, the choice is obvious. In fact, No choice.

#1 famous undefined behavior C++

(See below for smart ptr, template, non-RTTI)

Deleting [1] a derived[3] object via a base[4] pointer is undefined behavior if base[6] class has non-virtual dtor.

This is well-known but it applies to a very specific situation. Many similar situations aren’t described by this language rule —
[1a] This rule requires pointer delete. In contrast, automatic destruction of a non-ref “auto” variable (on stack) is unrelated.

[1b] This rule requires a heap object. Deleting a pointee on stack is a bug but it’s outside this rule.

[1c] This rule is about delete-expression, not delete[]

[3] if the object’s run-time type is base, then this rule is Inapplicable

[4] if the pointer is declared as pointer-to-derived, then Inapplicable

[3,4] if the object run time type is base, AND pointer is declared pointer-to-derived? Inapplicable — compiler or runtime would have failed much earlier before reaching this point.

[6] what if derived class has non-virtual dtor? Well, that implies base non-virtual too. So Yes applicable.

*) P62 [[effC++]] points out that even in the absence of virtual functions (i.e. in a world of non-RTTI objects), you can still hit this UB by deleting a subclass instance via a base pointer.

**) The same example also shows a derived class-template is considered just like a derived class. Let me spell out the entire rule — deleting an instance of a derived-class-template via a pointer to base-class-template is UB if the base class-template has a non-virtual dtor.

What if the pointee is deleted by a smart_ptr destructor? I think you can hit this UB.