Structure of platform specific vs non platform specific code

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-05-08 23:16, Igor wrote:
> Hi,
>
> I am following Casey Muratori's Handmade Hero and writing it in DLang. I
> got to Day 011: The Basics of Platform API Design where Casey explains
> the best way to structure platform specific vs non-platform specific
> code but his method cannot work in DLang since it uses modules and I am
> wondering what would be the best way to achieve the same in DLang.
>
> His way is to have these files:
> - platform.cpp (includes game.cpp directly, not game.h)
> - game.h (declares non-platform specific data types for communicating
> with platform layer and both game functions that platform layer needs to
> call and platform functions that game needs to call)
> - game.cpp (includes game.h and defines declared game functions)
>
> This scheme makes preprocessor actually merge all files into one but
> logically game.* files see nothing that is platform specific.
>
> The best idea for DLang I have is to separate platform into two modules:
>
> - platform.d (contains only code that needs to call into game code so it
> imports game.d)
> - platformServices.d (contains only code that game needs to call but
> wrapped in a common abstraction layer so game.d imports it)

When it comes to platform specific code, one way to do it is to use one 
module per platform and then one common module that publicly imports the 
platform specific modules:

module linux;

module windows;

module osx;

module platform;

version (linux)
     public import linux;

else version (Windows)
     public import windows;

else version (OSX)
     public import osx;

else
     static assert("unsupported platform");

Without having looked at the above mentioned guide (or whatever it is), 
I would say that it would make more sense that if the game module 
imports that platform module than the other way around.

-- 
/Jacob Carlborg