In order to perform a modular C++ project, interface and library are widely used.
Let us review the interface first:
virtual bool dosomething() = 0;
To implement this interface, we have to provide a way to create as well.
class ABCImpl: public ABCInterface
virtual bool dosomething() override;
void DestoryABC(ABCInterface* obj);
Thanks linker, and OS loader, they can help automatic loading so/dll who exported the create function.
but if you want to hide the linking procedure, we can introduce a factory class to manage the create procedure, you can receive an object pointer if you provide the class name(of course, it cannot be perfect, this is c++, it is strong type language).
Let us start reviewing our object factory evolution path:
v 1.0 PluginKernel – yang @ 2010
- it loads all dlls from specified folder, and dlls will user global variables to auto register classes.
- no need to care where is the class(similar to C++ static linking, but this is dynamic)
- it requires application to load dlls at starting, so it takes time, it also no lock inside.
- the library is closed-source(some components loaded through this interface are also closed-source), until 2 years later(around 2013). we can got some exception if it got problem. so debugging is a problem sometimes.
class CPluginAutoReg: used to register a class(store create, destory function pointer), usually declare as a global variable
class CCommonPluginAutoReg, class CSingletonPluginAutoReg: wrap class to create object
template class PluginAutoPtr: store the created object, becaue it is a template, you can attach interface when using this template, easier to write final code.
plugkernel apis: these api are used by above classes to register,create.
a snapshot of v 1.0
v 1.1 PluginKernel – yew- yuy @ around 2013
Due to our boss complains the product was too slow, also due to many components are closed source. we added a lock inside pluginkernel after we got pluginkernel project source code. so that we can load some libraries later(to load in a work thread).
- add a lock inside this library, so that we can load some libraries in work thread, to improve the product startup speed.
- manually grouped libraries into two. one of them are loaded in a work thread.
v 2.0 objmanager – xiaole @ Sep 2014
This project is made due to a product is under re-construction.
- it added dll name in the object. so a class name was changed from ‘someclass’ to ‘somedll@someclass’. this is a great improvement. no longer need to pre-load dlls, we can load dll when creating objects on demand
- no longer require to pre-load all dll files
- you need to take care raw pointers when creating/destroying
class objregister: the wrap class for registration
template class objregisterImp: it is used to store create,destroy function.
class ObjManager: it is the factory for creating objects, it stores all creating/destroy function point.
v 2.1 – xiaole
moved the code to a higher level project, no functional change
v 2.2 baseobj – yuy
- added a base class baseobj, it requires classes to derive from this
- added a template class ObjPtr, it works similar to a shared_ptr
- ObjManager is renamed to ObjHost
- based on v 2.0/2.1, v 2.2 has a template class to make coding easier.
- it requires classes to derive from the new class.
v 2.3 yuy
minor change from v 2.2:
- added isNull, isValid for pointer checking
v 2.4 jian ann
the v 2.1/v2.2 has ObjPtr class, but it couldn’t manage object properly. so jian ann and yew from another team gave a hand to review the code.
in v 2.4 ObjPtr is removed, added a template function MakeObject, and using shared_ptr destructor to handle cleaning task
- ObjPtr is replaced with stared_ptr, using MakeObject to create objects.
- it solved crash introduced in v 2.1
v 2.5 jian ann
- add a mutex inside ObjManager, now it is thread-safe
- solved the multi-thread issue inside ObjManager
v 2.6 yew
- added singleton support
- added reference counting to dll, we can release a dll when no object is active now. we need this because many objects are global/static, they will be recycled until a dll is unloaded
v 2.7 (the current in use version, contains all changes after 2.6)
- added more log for troubleshooting
- release all dlls when ObjHost is going to destroy
a snapshot of v 2.x
v 3.0 (maybe) objbase – yew @ dec 2016
it is the end of 2016, after more than 2 years development, the product plans to release, due to many crashes, need to review code again. partially due to hasn’t touched this project for about 2 years, jian ann felt the code is over-engineered, hard to debug. Because similar classes are the foundation of the product, used in many places, not easy to make a change.
After revamping some other components, yew decided to rewrite this. Because we have very clear requirement now. and it is the time to use more modern language features.
- only one header file, and one class ‘ObjBase’, it uses shared_ptr and lambda expression to store data and carry out cleaning logic
- provided compatible macros with v 2.7, so application code can remain unchanged
- more clean implementations
- supports full features included in v 2.7
a snapshot of v 3.0
you can get v3 source code from here: