DMD 1.005 release

[Walter Bright]

Anders F Björklund wrote:
> Walter Bright wrote:
>> I've also tried the "make an API for the version" method, and have 
>> been much more satisfied with it. You can see it at work in the gc 
>> implementation (see gclinux.d and win32.d).
> 
> OK, see what you mean. And the Makefile would pick which
> implementation gets used, for the common interface chosen ?

Yes, that's a reasonable way to do it.

> Not sure there's a whole world of difference between the:
> 
> version(Win32) // or foowin32.d
> void foo() { ...this... }
> version(linux) // or foolinux.d
> void foo() { ...that... }
> 
> and
> 
> void foo()
> {
> version(Win32)
> ...this...
> version(linux)
> ...that...
> }

There isn't if the functions are trivial. But when they get more 
involved, it becomes a mess. How many times have you had to compile with 
just the preprocessor just to figure out which branch of the rat's nest 
of #if's was actually getting compiled?

Many years ago, when assembler coding was popular, Microsoft produced a 
macro library to make coding in assembler sort-of-but-not-quite-like 
coding in some pseudo-high level language. The layers of macros was so 
bad that a friend of mine, in order to work on such code written by 
others, resorted to assembling it, *disassembling* the result, and 
pasting the disassembled source back into the source file and started over.

> But any rate, it's preferred to handle it outside of D. OK.
> Either through rewriting the code, or in the Makefiles. OK.
> 
> With autoconf, I normally want the SAME piece of code to
> work on all platforms - so it does a different approach.
> 
> For D, I would instead write one piece of code for EACH
> platform and avoid versioning it (as much as possible) ?

Yes, in the end, I think that's a more maintainable solution. You'll 
find your core modules will become much more portable, and you shouldn't 
need to edit (or even understand) them at all when porting to a new 
platform.

If your job is to port the gc to a new XYZ platform, would you find it 
easier to edit the long and complicated gcx.d, or just copy gclinux.d to 
gcXYZ.d and restrict your work to just figuring out how to port a few 
lines of code with (hopefully) well-defined behavior?


> I've worked with the "./configure && make" approach for
> many years and kinda like it, but will try out new ideas.
> Then again I kinda like the preprocessor too, and prefer
> writing C over C++, so maybe I'm just stuck on the old. :-)
> 
> Not changing anything for the "ported" projects (like wxD),
> but it will be something to keep in mind for future D ones.
> Will do some thinking on how it would apply to options...
> (choices, as opposed to just platform/portability macros)
> 
> --anders