• chris schoeneman (21/21) Aug 21 2001 if i've got a module with some platform specific code (maybe asm
• weingart cs.ualberta.ca (Tobias Weingartner) (6/14) Aug 22 2001 At the current time, if you are talking C (sometimes even C++) code,

chris schoeneman <crs shutterfly.com> writes:

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

weingart cs.ualberta.ca (Tobias Weingartner) writes:

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.