Re: [Alephmodular-devel] File organization and multiple platforms?

[Woody Z. I. <woo...@sb...>]

On Monday, January 27, 2003, at 07:59  PM, Br'fin wrote:

> 	<class file>.h
> 	<class file>.cpp
> 	<class file>_<platform>.cpp
>

Don't forget <class file>_<platform>.h; different platforms could 
provide different interfaces (probably extended in one way or another) 
and various bits of code may want to get at those extensions (after 
checking their availability, perhaps with dynamic_cast<> e.g.).

Naturally the 'main interface' should cover as much as possible, but 
that doesn't necessarily mean it would be wise to restrict all uses to 
only that interface.

Actually hmm, how exactly should this work out?

// Class.h
class IClass { all pure virtual, virtual destructor };

// Class.cpp
(do-nothing destructor)

// Class_Shared.h
class CClass_Shared : public IClass { methods that most folks will be 
able to use regardless of platform };

// Class_Shared.cpp
(implementations for those)

// Class_Carbon.h
class CClass_Carbon : public CClass_Shared { platform-specific methods, 
including perhaps overrides of some in CClass_Shared };

// Class_Carbon.cpp
(implementations for those)

This way a platform that does things radically different or something 
can use only the interface, and not inherit any of the default behavior 
of the shared class.  OTOH platforms that have a lot in common can share 
that common code.  ("Template Method", anyone?)

Perhaps Class_Shared should have a more descriptive identifier than 
"Shared", that indicates something about its implementation approach - 
so that there can be other shared superclasses later that take a 
different approach.

Of course whenever practical, CClass_Shared should target a 
platform-neutral interface, and accept one or more platform-specific 
helper objects that implement that interface (perhaps requested from a 
Factory) to do its work, to help avoid 'combinatorial explosion'.  But I 
probably didn't need to state that.

Woody