minwin

[Tomas Lindquist Olsen]

Walter Bright wrote:
> Gregor Richards wrote:
>>>     version (NOTWINDOWS) => version (LINUX)
>> I hate to say this, but that example just plain stupid. All it will 
>> ever do is limit your code to work on only certain operating systems. 
>> That's hindering portability, and that's no good.
>>
>> As it turns out, it's often the case that such-and-such does work on 
>> every sane operating system, and therefore version (!Windows) makes 
>> sense.
> 
> I've seen a lot of code that did that, and it was nearly always broken. 
> That's one motivation for operating system versions should be positives, 
> not "this is for not windows" or "this is for not linux". Such 
> fundamentally are wrong, and will bite you or the maintainer sooner or 
> later.
> 
>> I know I've ran into instances where $WEIRD_SOCKET_FEATURE_X crashes 
>> horribly on a certain operating system, so I was forced to #ifndef 
>> __APPLE__. The same feature worked fine on literally every other 
>> system I tested it on, so it would be ridiculous to do an #ifdef for 
>> everything BUT Apple.
>>
>> version (darwin)
>> version (BSD)
>> version (Solaris)
>> version (SkyOS)
>> version (DJGPP)
>> version (HURD)
>> version (ObscureOS)
>> version (OSYetToBeInvented)
> 
> What I'd do is have APPLE_SOCKET_BUG with the workaround, and the 
> default for the else. That way, you can search for the workarounds for 
> that bug, and they won't be confused with other apple features or other 
> apple bugs. Furthermore, if apple fixes that bug, you can update your 
> code much easier with a targeted update than if you painted the entire 
> apple os that way.
> 
> It's common practice (such as in STL) to target specific bugs with 
> specific identifiers, and then have a configuration file which sets up 
> the bugs for each system.
> 
>> Thinking in positives is great, but so unrealistic as to be completely 
>> valueless. version statements in reality are used like indexes into 
>> sets. The set of operating systems, the set of C libraries, the set of 
>> compielrs. And it's unrealistic and ignorant to try to index EVERY 
>> member except for whichever one you like, especially since the list is 
>> always growing.
>>
>> Not everything has a positive opposite. In fact, most everything doesn't.
> 
> I don't agree, and as an example I suggest the socket bug approach above.

This discussion has made me remember something I though about a while ago...
While I understand the reasoning for disallowing negated version 
identifiers / version statements from the above, I dont understand why 
we can't use logical operators with versions:

version(Windows)
{
     writefln("I know your OS");
}
else version(linux)
{
     writefln("I know your OS");
}
else version(darwin)
{
     writefln("I know your OS");
}
else
{
     writefln("I don't know your OS");
}

VS.

version(Windows || linux || darwin)
{
     writefln("I know your OS");
}
else
{
     writefln("I don't know your OS");
}

This genuinely reduces code duplication and is thus according to 
standard D mentality: less prone to be buggy, easier to maintain, and 
faster to write.
Though if something like this was to be allowed, && and ! probably 
should be as well.
IIRC the reason I wanted something like this was for a demo where I use 
a proprietary library that only supports win32 and linux, and thus those 
two versions wants a single implementation, all other will not use it at 
all.

I realise this can be done with something like:

version(Windows) version=OK;
else version(linux) version=OK;
version(OK)
{
	...
}
else
{
	...
}

but just:

version(Windows || linux)
{
	...
}
else
{
	...
}

is clearer IMHO.