oop and binary modules - 1

1. use case - a class implemented in static library
use case - a class implemented in shared library


2. when a eclient uses this , it will first instantiate the class directly, or derive a class
from the above and then instantiate, or it will derive a class and store it in static/dyn lib

3. there is a module boundry between static and dynamic library

4. internal symbol infos are stored per module.c++ name mangling is global per string.same compiler
will give same mangle for the same string across

5. when a class is stored in static or dyn, its mangled symbol info is stored in a stub inside the module

6.when a client uses this class, step one is loading the binary into its space, second resolving names.A memory block is created for the object, then it needs to patch up the function references
in the memory object.for that it consults the stub and fills its load addresses into function table.it means object memory can be global among the loaded address space.though the main class
and subclass implementations belong to different modules, the global unique object of base class
and subclass will contain references to method addresses in differnt modules.

it also implies that the data is stored in global store.global means the process space.

if RTTI is enabled it can identify any objects type in process space.

client(binary) uses class 1

class1(static) class2 der class1(dyn) class3(dyn)

here when client instantiates class1, it has to load class 2 module and its methods will
be resolved auto.the class1 obect will have its base class method in static lib and
derived class methods in dll

when access to virtual method of class 1 is done it will call into either staic module or dll

class 1 gives a uniform interface to methods behind it.client doesnt know whether the implementation is in staic or dynamic lib.

if at the time of instantiation, class 1 could specify from where the dll is loaded then
clients main code becomes decoupled from the static and dynamic

so it becomes
class A-1 classA-2 ..... (binaries)
=================================================
client object selection (selects based on string) (different binaries)
client main logic(will not change ever)


4.if base class is a binary dyn,derived is also binary dyn can it happen
yes if the client loads the base class and derived class into its space before using them
at lazy binding.the created object will resolve to dyn1 for base class and dyn2 for derived class

5.At compilation time there can be a problem, there will not be base class addresses available when compiling derived binaries.how will compiler provide support for this

same applies to client, at compile time client doesnt have symbol access to base and derived

6.a game app can be viewed as

module layers ... all dlls are present in this layer,they may be base classes or derived classes
base and derived can be in separate dlls

client layer interface - a layer that loads members of module layer

client logic - a layer that makes use of base type object to do all the complicated work,here
its assumed that all the classes in thae module layer is somehow derived from base type obect

module layers are separate binaries,client lay intf can be separate binaries,client logic can be separate binaries

7.what if 2 dlls contain same function same prototype ,both expost this function.a client loads the dll and tries to import the function.will compiler give warning or its runtime