DynObj - Overview
Features of the DynObj Library
It makes sense to think of DynObj as a type information system
that is shared between libraries/executables compiled by
different (possibly different language) compilers:
Point (4) implies that DynObj can handle multiple types of
object ownership (i.e. ref counting is not enforced).
- Interface classes are shared formally.
- The binary layout of a compound object is exposed in
a well defined way.
- Intefaces and class hierarchies can be used intuitively
and directly across plugin boundaries.
- All interface classes can be shared, also those that don't
derive from a single default root interface (such as
IUnknown in COM).
- A language neutral representation of type information is used.
The last point means that DynObj plugin libraries can be implemented
in compiled languages other than C++ (and also used from other languages).
There are other approaches that does similar things (xpCOM, COM,
and CORBA). These are some differences:
The DynObj library is more lightweight and not dependant on a large code
base or OS specific.
- The DynObj library is based on a shared type system, it does
not rely on a member function QueryInterface, to
retrieve interfaces. The DynObj type system does this work silently.
- A wider range of types is handled (since a root base interface is
- It allows for different object ownership models (strong/shared/weak).
- DynObj does not rely on an IDL layer. Interface definitions are
are ordinary classes and not weighted down by a heavy use of
Other libraries have features such as out-of-process
execution, distributed objects and much more, areas which DynObj does not