James Pelcis wrote:
> If you are writing a program that will only work on Windows, it would be necessary to use this...
> 
> version (Windows)
> else
> {
>     static assert (0);
> }

Instead of:

	... windows code ...
	version (Windows)
	else
		static assert(0);

I suggest:

	version (Windows)
		... windows code ...
	else
		static assert(0);

On Thu, 11 May 2006 18:24:17 -0700, Walter Bright wrote:

> James Pelcis wrote:
>> If you are writing a program that will only work on Windows, it would be necessary to use this...
>> 
>> version (Windows)
>> else
>> {
>>     static assert (0);
>> }
> 
> Instead of:
> 
> 	... windows code ...
> 	version (Windows)
> 	else
> 		static assert(0);
> 
> I suggest:
> 
> 	version (Windows)
> 		... windows code ...
> 	else
> 		static assert(0);

However, the important thing is to convey information to code maintainers. And the most direct and simplest way is to have this at the TOP of your source code ...

  version (Windows)
  else {
        pragma(msg, "Only compilable in Windows environment.");
	static assert(0);
  }

  ... windows code ...

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
12/05/2006 11:53:48 AM

In article <e40ehq$2pgs$1@digitaldaemon.com>, Walter Bright says...
>
>pragma wrote:
>
>> Walter, I mean no disrespect here, but I simply must ask: Are you talking about
>> a literal interpretation of version() and debug(), including the lack of an
>> #ifndef equivalent?
>> 
>> Like this:
>> 
>> #ifdef FOOBAR
>> #else
>> /*** code ***/
>> #endif
>> 
>> Or like this (using ifndef):
>> 
>> #ifndef FOOBAR
>> /*** code ***/
>> #endif
>> 
>> I don't think that version() and debug() need to be tangled up with all kinds of boolean expressions, but maybe a short-and-sweet concession to allow an equivalent to #ifndef is in order?  Sure its just "one line more readable" but it *is* more readable after all.
>
>Consider another perspective: when a version of the code is being built, one thinks about a version being build, not a "not version". If you find that you're writing:
>
>version (FOOBAR)
>else
>{
>	...
>}
>
>I suggest that perhaps FOOBAR is the wrong name for the version being compiled. For example, I would red flag code that looked like:
>
>version (Windows)
>else
>{
>	...
>}
>
>I also have a particular dislike for the execrable double negative style often seen in C:
>
>#ifndef NO_FOO
>...
>#endif
>
>There is some psychobabble research on this, suggesting that people tend to skip nots, and even more often miss double negatives. I know that in airplane pilot jargon, considerable effort has been made to purge negations and replace them with positive statements, as they are less prone to misinterpretation.
>
>Some more examples:
>
>1) Don't build a "NOTFULL" version, build a "DEMO" version.
>2) Don't build a "NOTDEMO" version, build a "FULL" version.
>3) Don't build a "NOHARDTABS" version, build a "SOFTTABS" version.
>
>etc. If there are some specifics cases you feel just don't fit with this, can you post them?

Actually I don't have anything to cite that would be contrary to this - especially after your explaination, thank you. :)

I never thought to look at versioning that way, and I'm glad that you took the time to explain it all out. Perhaps we've all been flipping bits back and forth too much to realize that "false" and "!true", while semantically the same thing, may lead to different uses and interpretations (and mis-interpretations).

You've given me much to think about.

- EricAnderton at yahoo

Derek Parnell wrote:
> On Thu, 11 May 2006 18:24:17 -0700, Walter Bright wrote:
>> I suggest:
>>
>> 	version (Windows)
>> 		... windows code ...
>> 	else
>> 		static assert(0);
> 
> However, the important thing is to convey information to code maintainers.
> And the most direct and simplest way is to have this at the TOP of your
> source code ...
> 
>   version (Windows)
>   else {
>         pragma(msg, "Only compilable in Windows environment.");
> 	static assert(0);
>   }
> 
>   ... windows code ...

I suggest that if the entire module was windows only, put it under a windows package.

Walter Bright wrote:

> Shipping production code for an OS that has never been even tried on that OS is not a good idea. In that case, having an assert in it *is* better because it's a red flag for the maintainer of that OS that he's got some work to do folding in new capability, and most importantly testing it.

Hmm, that sounds like a lot of work...

So, basically, if I want portable code I should stick to C and Java ?
(C with autotools for feature detection, that is. For GNU platforms)

--anders

pagma wrote:
> In article <e4069c$2da5$1@digitaldaemon.com>, Ameer Armaly says...
>>
>> "Derek Parnell" <derek@psych.ward> wrote in message news:op.s9d3gilp6b8z09@ginger...
>>> On Thu, 11 May 2006 19:32:07 +1000, Don Clugston <dac@nospam.com.au> wrote:
>>>
>>>
>>>> Since "static if" is now legal at module scope, it's now practically a superset of "version". So it shouldn't be very complicated to move some of the functionality across. (There's a problem with using 'static if' instead of 'version' : if there's an 'import' statement bracketed by a static if, potentially you have to compile the program to find out which files are included. Obviously 'build' can't cope with that).
>>> And I don't want to make Build be a compiler too ;-) So I don't think it will ever try to execute static if statements.
>>>
>> Just a random thought, but what about moving at least some of the project functionality of build directly in to the compiler; have it compile all current directory imports and link them together.  If -c is supplied, then the compiler would compile them only as opposed to linking, facilitating flexible build processes.  An advantage of this sort of approach is that the compiler already needs to know all about imports and locations, so the logical extension of that idea would be to have the compiler act on them. This is just something I came up with randomly while reading this thread; I don't know whether or not it's been proposed before.
> 
> AFAIK its been proposed before.  I think the opinion of many was that the
> benefit of having many utils that each do a particular job well, outweighs the
> strengths of a single swiss-army-style application; hence the term "toolchain".
> This also happens to be the main philosophy behind Unix in general, and (IMO) is
> one of the main reasons why the parts that have always worked well continue to
> do so. :)
> 
> Also, In the case of DMD and Build, each is maintained by a separate person - we
> get far better man/hr per LOC coverage this way than if Walter has to manage
> both feature sets. ;)
> 
> - EricAnderton at yahoo

On the other hand, it happens that here that the "each do a particular job well" has something to be said: there is much overlap in the jobs of both utils (the compiler and build), such in fact that I think their jobs are not that different.
And as an example, the java compiler (javac) does this.


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Sean Kelly wrote:
> Anders F Björklund wrote:
>> Walter Bright wrote:
>>
>>>> I'm still naively hoping for both of "version (Unix)"
>>>
>>> DMD supports Windows and Linux; Unix is neither. For a compiler which targets the Unix operating system, it should set the Unix version.
>>
>> It does... I was just hoping to be able to use the same code for both ?
>>
>> GDC has chosen "Unix" as the name for all of them, while Ares uses "Posix". The naming doesn't matter as much, as long as it is defined.
> 
> For what it's worth, I chose "Posix" because it refers to the API rather than to a subset of systems that support that API.  But I agree that both are sufficiently general that they could be considered equivalent.
> 

Are they (equivalent)? How about Cygwin which "is a DLL implementing most of the POSIX API on top of Windows". Does it count as Unix? How can this fit into D's (current or alternative) versioning scheme of things?


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Sean Kelly wrote:
>> Anders F Björklund wrote:
>>> Walter Bright wrote:
>>>
>>>>> I'm still naively hoping for both of "version (Unix)"
>>>>
>>>> DMD supports Windows and Linux; Unix is neither. For a compiler which targets the Unix operating system, it should set the Unix version.
>>>
>>> It does... I was just hoping to be able to use the same code for both ?
>>>
>>> GDC has chosen "Unix" as the name for all of them, while Ares uses "Posix". The naming doesn't matter as much, as long as it is defined.
>>
>> For what it's worth, I chose "Posix" because it refers to the API rather than to a subset of systems that support that API.  But I agree that both are sufficiently general that they could be considered equivalent.
> 
> Are they (equivalent)? How about Cygwin which "is a DLL implementing most of the POSIX API on top of Windows". Does it count as Unix? How can this fit into D's (current or alternative) versioning scheme of things?

I suppose that depends what "Unix" means to you.  Windows also has a Posix subsystem, Interix, which should definately classify as Unix.  So you could theoretically have Windows, Win32, Unix, and Interix all defined for a Windows platform.  Personally, I find Posix to be more meaningful here, but it's splitting hairs.


Sean

Bruno Medeiros wrote:

>> For what it's worth, I chose "Posix" because it refers to the API rather than to a subset of systems that support that API.  But I agree that both are sufficiently general that they could be considered equivalent.
> 
> Are they (equivalent)? How about Cygwin which "is a DLL implementing most of the POSIX API on top of Windows". Does it count as Unix? How can this fit into D's (current or alternative) versioning scheme of things?

For GDC, Cygwin is being auto-generated just like the other "Unix" ones.
i.e. Unix = Linux | Darwin/Mac OS X | FreeBSD | Cygwin/MinGW | AIX | ...

But as far as I know Cygwin is a Linux API emulation, and thus not Unix.
It's just bundled under that version(Unix) in GDC, along with the other.

--anders

Sean Kelly wrote:
> Bruno Medeiros wrote:
>> Sean Kelly wrote:
>>> Anders F Björklund wrote:
>>>> Walter Bright wrote:
>>>>
>>>>>> I'm still naively hoping for both of "version (Unix)"
>>>>>
>>>>> DMD supports Windows and Linux; Unix is neither. For a compiler which targets the Unix operating system, it should set the Unix version.
>>>>
>>>> It does... I was just hoping to be able to use the same code for both ?
>>>>
>>>> GDC has chosen "Unix" as the name for all of them, while Ares uses "Posix". The naming doesn't matter as much, as long as it is defined.
>>>
>>> For what it's worth, I chose "Posix" because it refers to the API rather than to a subset of systems that support that API.  But I agree that both are sufficiently general that they could be considered equivalent.
>>
>> Are they (equivalent)? How about Cygwin which "is a DLL implementing most of the POSIX API on top of Windows". Does it count as Unix? How can this fit into D's (current or alternative) versioning scheme of things?
> 
> I suppose that depends what "Unix" means to you.  

I don't know exactly what it means. My knowledge of what exactly is "Posix" is also very dim.
I just wanted to mention this detail, I'll leave the thinking on this subject to you[plural you].


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D