c++base class method accessing subclass field #RTS IV

Surprisingly, the non-virtual base class method can Never know that it’s actually operating within a subclass instance. It always behaves as a strictly-baseclass method and can’t access subclass data. The non-virtual method getId() is compiled into base class binary, so it only knows the fields of the base class. When a subclass adds a field of the same name, it is not accessible to the getId(). A few workarounds:

  1. curiously recurring template pattern
  2. virtual function in subclass
  3. down cast the pointer and directly access the field
#include <iostream>
using namespace std;
struct B {
	char id = 'B';
	virtual ~B() {}
	char getId() {
		return id;
} b;
struct C: public B{
	char id = 'C';
} c;
int main() {
	B* ptr = new C();
	C* ptr2 = dynamic_cast<C*>(ptr);

	cout << "base class nonref: " << b.getId() << endl;
	cout << "sub class nonref: " << c.getId() << endl; //still base class method. 
	// The fact that host object is subclass doesn't matter.

	cout << "base class ptr to subclass instance: " << ptr->getId() << endl; 
	cout << "downcast ptr non-virtual method: " << ptr2->getId() << endl; //B
	cout << "downcast ptr direct access: " << ptr2->id << endl; //C
	return 0;



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

https://briangordon.github.io/2014/09/covariance-and-contravariance.html 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

Google c++ style guide forbids default args in virtual functions.

Ashish said he was asked a common question in multiple c++ interviews. The default arg value is “declared” in base class and (or) derived class but never 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 arg value applies unconditionally, even though the subclass method is chosen at run time, via the vtable. Highly confusing.

"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

y dynamic_cast returns NULL on pointers

https://bintanvictor.wordpress.com/2010/01/14/new-and-dynamic_cast-exceptions-quick-guide/ shows that dynamic_cast of a pointer returns NULL upon failure. Why not throw exception?

A: for efficient test-down-cast. dynamic_cast is the only solution. If it throws exception, the test would have to incur the cost of try/catch.

See P59 [[beyond c++ standard lib]]

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.

#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.

virtual function adding complexity #letter to friend


I guess why many C programming teams avoid virtual keyword is because this innocent-looking keyword can cause complexity explosion when mixed with other elements —

– dynamic cast for pointer or reference variables
– pure virtual functions
– slicing — without virtual, slicing is more consistent and easier to debug
– passing a RTTI object by reference — note an object is an RTTI object IFF it has a virtual pointer.
– throwing an RTTI exception object by reference, by pointer or by value — again, things are simpler without virtual
– member function hiding (by accident) — without virtual, the hiding rule is simpler
– non-trivial destructors
– pointer delete — for example, deleting a derived object via a base pointer is undefined behavior if the destructor is non-virtual. If you avoid virtual completely, we would less likely write this kind of buggy code.
– double pointers — pointer to pointer to an RTTI object
– double dispatch — usually involves virtual functions. Double-dispatch may not be very meaningful to non-RTTI objects.
– container of RTTI objects, such as vector of pointer-to-base, where each pointee can be a Derived1 object or Derived2 object… — again, non-RTTI cases are simpler
– templates — remember STL internally uses no virtual function, and perhaps very little inheritance
– smart pointers holding RTTI objects
– private inheritance
– multiple and virtual inheritance

Some experts advocate all base classes should have virtual destructor. In that case, avoiding virtual means avoiding inheritance. That would definitely reduce complexity.

make dtor pure-virtual 2make class abstract #Google

Many c++ authors say that if you want to make a non-abstract base class abstract, but don’t have any method to “purify” (i.e. convert to pure-virtual), then a standard practice is to purify dtor by adding “=0” at end of the already-virtual dtor.

Note: all base classes should have their dtors virtualized, according to many authorities, but Google style guide says “only if base class has virtual methods”

I wonder why not add a dummy pure-virtual method. (I think in practice this is fine.)

I believe the answer is efficiency, both space-efficiency and possibly run-time efficiency. Adding a dummy pure-virtual adds to every class size and vtbl size, but not instance size. Also every non-abstract sub-class must implement or inherit this dummy method.

const T =shadow-type of T;const T&=distinct type from T&

(background: the nitty gritty of overload/overriding rules are too complicated…)

I feel overloading and overriding has consistent rules. Take 2 same-name functions (single-param functions for simplicity) and ignore their host classes. If the 2 can overload each other, then their parameters are considered distinct. That means they can’t override each other (if they were inserted into a inheritance tree).

Conversely, if the 2 can override each other, then their parameter types are considered “identical” so they can’t overload each other (if set “free”).

Q: We know function overloading forbids 2 overloads with identical parameter sets. How about const, i.e. If 2 functions’ parameters differ only in const, can they have identical names?
A: No. ARM P308 explains that compiler’s (static) “resolution” (based on argument type) will fail to pick a winner among the 2. It’s ambiguous.
A: therefore, in the overloading context, const SomeType is a “shadow type” and does NOT count as a distinct type.

However, if 2 functions’ parameters have this difference — const T& vs T&, then distinct types, so the 2 functions can have identical names. Exaplained in ARM.

Similarly, 2 overloads can overload based on const T* vs T* — distinct types.

Q: We know method overriding requires exact parameter match. How about const? Can an override add or remove const?
A: whatever the answer, this is sloppy. No justification.
A: yes according to my test. Adding the const makes no difference — runtime binding unobstructed.
A: therefore, in the overriding context, const SomeType is a “shadow type” and does NOT count as a distinct type.

However, my test shows const T& vs T& do make a difference — runtime binding disabled. These are considered 2 distinct types.