Re: [Alephmodular-devel] File organization and multiple platforms?
Status: Pre-Alpha
Brought to you by:
brefin
From: Br'fin <br...@ma...> - 2003-01-30 03:19:15
|
On Wednesday, January 29, 2003, at 11:26 AM, Woody Zenfell, III wrote: > 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.). D'oh, I forgot about that file. *and* I was planning on using such features. :) And yes, it's ok for a mac platform to dynamic_cast the file objects to another likely state. > 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) I'm hazy on creating a pure interface versus a base one. I'm jut not experienced enough to know which way to lean when it's not obvious. With a pure interface though, there's nothing to destruct with that virtual destructor. So Class.cpp is unneeded in the situation listed above. My own thinking was to have what you have listed as Class_Shared pushed into Class.h/Class.cpp. If a sub class needs a major overhaul, well the interface is there to extend upon, overriding everything. And if it really can't use the common stuff, then perhaps we built things wrong. Agreed on the platform specific files. > 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. > I'm not sure what you mean by 'combinatorial explosion'. (It looks like a bunch of those cases where you say 'I don't need to expound on this' you actually do, if just because I'm dense) Also not sure of the difference between a subclass that does foo gotten from a factory and a class that does foo with the aid of a subclass gotten from a factory. Unless you mean it allows other classes to go new MYClass and it automatically starts delegating to an internal platform object derived from a factory... -Jeremy Parsons |