if i've got a module with some platform specific code (maybe asm or maybe an OS specific API) but mostly platform independent code, what's the best source file organization to use when porting to another platform?

i see the following possibilities:

  1. independent and dependent in all-platform source file
  2. independent and dependent in per-platform source file
  3. independent in module A, dependent in module B (BX, BY, ...)
  4. independent in superclass, dependent in subclasses

choice (1) requires conditional compilation, which i didn't see
as an option.  choice (2) means duplicating the independent
code, a Bad Thing.  choice (3) breaks apart tightly related
code and might require subverting access control, also Bad.

choice (4) seems reasonable but can the import statement for the subclass indicate the target platform?  if not then do all platform specific subclass modules have to have the same name?  or do you avoid importing the subclass altogether, somehow load the module at runtime, construct the object through an exported function, and let the virtual function dispatch do the rest?

-chris

In article <3B82B19A.7D430805@shutterfly.com>, chris schoeneman wrote:
> 
> if i've got a module with some platform specific code (maybe asm or maybe an OS specific API) but mostly platform independent code, what's the best source file organization to use when porting to another platform?
>
>   3. independent in module A, dependent in module B (BX, BY, ...)
>
> choice (3) breaks apart tightly related code and might require
> subverting access control, also Bad.


At the current time, if you are talking C (sometimes even C++) code,
this is the only viable option.  Yes, if "breaks" apart tightly related
code.  What you are missing, is that this boundary is an API.  Keep
it as an API boundary, and your code will be ifinitely more portable.

--Toby.