Why version() ?

[Walter Bright]

Derek Parnell wrote:
> On Tue, 10 Feb 2009 14:01:29 -0800, Walter Bright wrote:
> 
>> Derek Parnell wrote:
> 
>>>  ... it creates a new problem; code
>>> duplication.
>> I don't think that duplicating a small run of code is a problem.
> 
> 
> My apology. The problem is more than run-time performance issues. The more
> pressing problem, IMHO, is the one of maintenance costs. Duplicated code is
> a significant cost burden. Not only may each duplication require updating,
> but there is extra effort in analyizing every duplicate to see if it *does*
> need updating. And every act of updating increases the opportunity for
> introducing bugs.

Let's take an example, like the enum for O_XXXX in std.c.linux.linux. 
Some of those values are common between platforms, and some are unique 
to particular platforms. So you might be tempted to write:

enum
{
     O_RDONLY = 0,
     O_WRONLY = 1,
     O_RDWR = 2,
     O_CREAT = 0100,
version(OSX) O_SYMLINK   = 0x200000,
}

instead of:

version (linux)
{
   enum
   {
     O_RDONLY = 0,
     O_WRONLY = 1,
     O_RDWR = 2,
     O_CREAT = 0100,
   }
}
else version (OSX)
{
   enum
   {
     O_RDONLY = 0,
     O_WRONLY = 1,
     O_RDWR = 2,
     O_CREAT = 0100,
     O_SYMLINK   = 0x200000,
   }
}
else
{
     static assert(0); // need platform support
}

The first version is definitely shorter. But is it easier to maintain? I 
argue that it is *harder* and *buggier* to maintain. Let's say I am 
using linux and I need to add O_APPEND to it. I just stuff it in like:

enum
{
     O_RDONLY = 0,
     O_WRONLY = 1,
     O_RDWR = 2,
     O_CREAT = 0100,
     O_APPEND = 02000,
version(OSX) O_SYMLINK   = 0x200000,
}

and it works great for linux. Now I port my code to OSX, and it 
mysteriously dies. After much frustration, I discover that O_APPEND for 
OSX is 8, not 02000. (Yes, this kind of thing has happened to me. I only 
found it by suspecting the problem, and then going through every fscking 
definition comparing it to the one in the system .h file. Yeech.)

Now let's try the other way. I add O_APPEND to the linux branch, and 
linux works great. Now I port to OSX, and the compiler dies with 
"O_APPEND is undefined". I know immediately exactly what is wrong, look 
up the .h file, and insert the right O_APPEND into the OSX version of 
the declaration.

Furthermore, when I build a FreeBSD version, the compiler bings at me 
for every declaration that needs some porting attention, instead of 
silently using the wrong values.

This would be even better if the OSX and linux declarations were split 
into separate "personality" modules. That way you can develop happily on 
OSX without fear of accidentally breaking linux support. You can defer 
dealing with the linux version until you actually on the linux machine 
and are in an efficient position to take care of it.


> Coders need languages that help them do their job, and one way to help is
> to reduce the need for duplicated code.

I know there's a risk by getting in the way of programmers wanting to do 
things a particular way. To do it, I have to be pretty convinced that 
there is a better way. The C preprocessor is like crack, everyone knows 
it's bad but they snort it anyway because it feels so good <g>. C++ was 
supposed to get a bunch of features that obviate the preprocessor, but 
have a look at the premier C++ library - Boost - which uses the 
preprocessor heavily. Boost also uses every last iota of what the 
preprocessor can do, because if your cpp implementation is not 100% most 
of Boost will not compile (I know this from experience, DMC++ is 100% now).


>>> Duplicating (nearly all of a) source file is NOT, repeat NOT, a
>>> satisfatory solution.
>> I'm not insensitive to this as I do it myself in maintaining Phobos. It 
>> is a problem, but not a huge one. I find that the meld utility (on 
>> linux) makes this chore a snap.
> 
> Because of D's limited support for text macros, I am using third party
> tools to get me out of this problem too. 

meld is particularly nice. Andrei showed it to me:

http://www.linux.com/feature/61372