The idea of bundling code and program into a layout (classes) and injecting it with different data (objects) leads to a ‘new’ way (newer than C) of organizing our programs through the worldview of objects. <\/p>\n\n\n\n
Every unit is seen as <\/p>\n\n\n\n
that is ready to interact with other objects.<\/p>\n\n\n\n
Encapsulation (through access control)<\/p>\n\n\n\n
The first improvement upon OOP is privacy (data encapsulation). You can have finer controls of what to share and with who. In C++, your options are:<\/p>\n\n\n\n
Granting certain class as friend<\/strong> (anywhere in the class declaration with protected<\/strong> has very few good uses other than preventing heap protected<\/strong> member variables are almost always a bad idea<\/a>.<\/p>\n\n\n\n Inheritance<\/p>\n\n\n\n The second improvement is to allow classes to build on top of existing ones. What gets interesting (and difficult) is when the child ‘improve’ on the parent by either by replacing what they have (member variables) and what they do (methods) with their own. <\/p>\n\n\n\n Static data members inherit REFERENCES <\/strong>to the parent<\/a>!<\/p>\n\n\n\n Inheritance AT LEAST always inherits an interface (can optionally inherit implementation).<\/p>\n\n\n\n Shadowing<\/p>\n\n\n\n Whenever the member (function or variable) name is used in any form<\/span> (even with different argument types or signatures), the parent member with the same name will be hidden. The behavior is called shadowing, and it applies unless you’ve overridden ALL versions (signatures) of Overriding<\/p>\n\n\n\n Just like C, C++ uses static binding that takes the programmer’s word for it for their declared types, especially through handles. Overriding is a concept only needed when you plan to upcast your objects (child accessed through pointer\/reference) to handle a broader class of objects but intend to the underlying object’s own version (usually child) of the methods (especially destructors) called by default. <\/p>\n\n\n\n We do this by declaring the parent method Overriding involves leaving clues in objects so the upcasted references can figure out the correct methods of the underlying objects to call. In C++ it’s done with having a [38] virtual only applies to methods’ signatures (function name and the data types in the argument list). vtable do not keep track of argument\u2019s default values (if assigned) for efficiency (it\u2019ll always read the static upcast, aka parent methods\u2019 default values).<\/p>\n\n\n\n Classes (after considering inheritance)<\/p>\n\n\n\n Design relationships<\/p>\n\n\n\nfriend class F<\/code>) exposes the non-public <\/strong>sections specifically to the friend F. This is often a ‘loophole’ to access control that finds few legitimate uses other than testing. <\/p>\n\n\n\nfriend<\/code> functions are traditionally used in binary (2-input) operator overloading, but the modern wisdom is to screw it and just leave it out there as free functions!<\/p>\n\n\n\ndelete<\/code> through base pointer non-polymorphically<\/a> (child destructor not called: BAD) by making the base destructor non-public<\/strong> (i.e. meaning it’d be impossible to have base objects on stack) while letting the child chain the parent’s destructor (child can’t access it if it’s marked as private<\/strong>). <\/p>\n\n\n\n
\n\n\n\nBase implementation MUST NOT be inherited<\/td> pure virtual methods<\/td><\/tr> Base implementation inherited by default<\/td> virtual<\/td><\/tr> Base implementation MUST be inherited<\/td> non-virtual (and not shadow it)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n virutal<\/code> parent methods which shares the same function name mentioned in child. <\/p>\n\n\n\nvirtual<\/code> and overriden at child.<\/li>using Parent::f(..)<\/code> declared at the child class.<\/li>Parent::var<\/code> or Child::var<\/code> so there’s no potential for ambiguities.<\/li><\/ul>\n\n\n\nvirtual<\/code> and implement the child versions (must be of the same function signature). Overriding only make sense for non-static methods because<\/p>\n\n\n\nParent::f()<\/code> and Child::a<\/code>, not a class type like Parent p; p.f()<\/code> and Child c; c.a<\/code>. There’s no object c<\/code> for you to upcast to Parent <\/code>so there’s place for polymorphic behavior.<\/li><\/ul>\n\n\n\nvtable<\/a><\/code> (pointers to overridable methods, often stored in .rodata with string literals) for each class in the hierarchy and each object contains a pointer to the vtable<\/code> that matches its underlying class.<\/p>\n\n\n\n
\n\n\n\n