Conditional compilation inside asm and enum declarations

[Walter Bright]

Andrei Alexandrescu wrote:
> Walter Bright wrote:
>> Andrei Alexandrescu wrote:
>>> Then I have the function right there with all versioned 
>>> implementations. To me that seems better than Phobos' existing style 
>>> of version'ing large portions of code, which inevitably results in 
>>> duplicating a lot of the functionality in two places.
>>
>> I wouldn't consider Phobos to be an exemplary example of how to do 
>> versioning, though it should be. I think much of it, like std.file, 
>> should be split off into os-dependent "personality" modules, much like 
>> the os api modules have been.
> 
> That would exacerbate code duplication. Consider:
> 
> version(Windows) void[] read(in char[] name)
> {
>     ...
> }
> 
> version(Posix) void[] read(in char[] name)
> {
>     ...
> }
> 
> S readText(S = string)(in char[] name)
> {
>    ...
> }
> 
> In my approach they are laid as you see them, which I find very 
> well-organized.


There is no duplication in:
============ std.file =======================
version (Posix) import std.file.posix;
version (Windows) import std.file.windows;

/* code common to both goes here, like readText() */
=============================================
that is not also in the layout you described.

But there's no hard and fast rule here, and since you are doing the 
actual work, I defer to your judgment on those cases.

> In your approach you'd define several files each 
> specialized for an OS, which would duplicate readText, or put readText 
> into a common file and have it include platform-specific files. Both 
> solutions are unnecessarily complicated to the simple and clear code above.

While individual details vary, having personality modules for an os 
offers some nice advantages:

1. It's pretty clear what is happening for each system.

2. An expert on OSA can work on the OSA implementation without risking 
breaking the OSB implementation for which he had no expertise.

3. By looking at which files changed, you can tell which OS support got 
updated and which didn't.

4. Porting to a new platform is easier as you've got a list of 
personality modules that need to be created, rather than version 
statements threaded through the file contents.

5. The "else" clause in OS version statements tend to be wrong when 
porting to a new system, meaning that each version has to be gone 
through manually - overlooking one doesn't always create an obvious error.

I think the std.core.sys.* modules illustrate the advantages nicely, 
especially considering the former kludge-fest bug-ridden way it was 
done. The core.stdc.stdio still needs some work in this regard, however.