DMD 1.005 release

[Anders F Björklund]

Walter Bright wrote:

>> Example of things I am thinking about are "__WXGTK__", "UNICODE",
>> or "HAVE_OPENGL". With C/C++, they're usually in a config.h file.
> 
> I've worked with the C approach for many years, and have gotten 
> increasingly dissatisfied with it. Over time, it leads to conflicting, 
> misused, overlapping version macros.
> 
> 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 ?

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

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) ?


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