Conditional compilation inside asm and enum declarations

[Andrei Alexandrescu]

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> In my approach they are laid as you see them, which I find very 
>> well-organized.
> 
> 
> There is no duplication in:
[snip]

I said there's either duplication or complication.

> 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.

Great, thanks!

> 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.

Not clear to me. It's happened to me more than once to fix a function 
without knowing that it's version()ed (your fault: you didn't indent it) 
and that there's a corresponding Windows function some miles away.

To me it's much clearer to have all specializations of a given piece of 
functionality close to one another. They'd naturally tend to converge, 
not diverge.

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

Ok.

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

I never look... :o)

> 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.

No. This is where your point gets destroyed. Unittests should dictate 
what must be done for porting to a new platform. Your approach forces 
either duplicate unittests, or collector files that add clutter.

> 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 try to avoid else. I want to implement setenv on Windows, I prefix it 
with Windows. I want to implement it on Posix, I prefix it with Posix. 
Then I write one unittest. Then when a new OS comes, setenv won't be 
found so the unittest can't run. Problem solved *much* better.

> 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.

I don't know about that.


Andrei