"BareBones" VersionCondition identifier for druntime

[Paulo Pinto via Digitalmars-d]

Am 19.10.2014 um 07:34 schrieb Walter Bright:
> On 10/17/2014 12:04 PM, Kevin Lamonte wrote:
>> What do y'all think?  Would you be comfortable with saying to people
>> implementing new runtimes, "please version your differences from
>> druntime in
>> this particular way" ?
>
> It's a good idea, but having a bunch of versions quickly devolves to an
> unmaintainable mess, in my experience. For one issue, when one adds a
> new piece of code, which versions apply in what ways? Once the number of
> versions exceeds a certain level, I've never seen it done right.
>
> A better solution is to have modules that "plug in" or not. The gc is
> designed this way.
>
> Also, dmd's source code is also (largely) done this way. Stuff that
> would normally be #ifdef'd is instead abstracted away to an interface.
> My experience with such techniques is they work well, are relatively
> problem free, and are much easier on the eyes.


On the Microsoft Office talk at CppCon about writting portable code, 
they state "#ifdef OS" are forbiden in the Office team.

Exactly because of this. It starts up just in one or two places, and 
eventually grows to a mess of pre-processor flow that no one can 
understand what the compiler is actually seeing.

They went through lots of pain when writting Word 6.0.

In C and C++, my approach is to have a common header file and 
implementation, with implementation specific code being named 
implementation_os.cpp

Incidently this is how Go toolchain works for writing OS and CPU 
specific code. Go packages are seen as name_os_architecture.go

--
Paulo