[pclasses-devel] supermacro-based factory registration mini-demo

[stephan b. <st...@s1...>]

Yo,

Consider the 3 classes we had earlier:

AType ==> extended by BType ==> x by CType

Here's how we can plug in factories for a set of classes:

#define PFACREG_TYPE AType
#define PFACREG_TYPE_NAME "AType"
#include <pclasses/FactoryReg.h>

#define PFACREG_TYPE BType
#define PFACREG_TYPE_INTERFACE AType
#define PFACREG_TYPE_NAME "BType"
#include <pclasses/FactoryReg.h>

#define PFACREG_TYPE CType
#define PFACREG_TYPE_INTERFACE AType
#define PFACREG_TYPE_NAME "CType"
#include <pclasses/FactoryReg.h>

That causes some back-end template code to register the classes with the 
AType factory. The registration happens during the static init phase of 
the app, which means before main() or during dlopen(). Thus all types, 
regardless of their linkage, have the exact same registration 
technique.

To use the default factories a type must be Default Constructable using 
'new', but clients can easily install their own back-end factories 
(using templates) which the factory API will pick up.

To re-use the FactoryTest example from earlier, it now works using this 
type of registration. The main implications/points are:

a) Same reg technique for all classes, regardless of linkage.
b) We have the same client API for loading types, regardless of linkage 
of loaded class: classload<T>(name). Clients automatically benefits 
from any DLL support which might be hidden behind the P API.
c) Also works with abstract types (add #define 
PFACREG_TYPE_IS_ABSTRACT).

The code for the supermacro is in include/pclasses/FactoryReg.h. Factory 
itself did not need to change to accomodate this.


See ya!

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts