version and debug statements

[Walter Bright]

Sean Kelly wrote:
> For what it's worth, I think it would be useful for the 'Posix' version 
> to be added, so any system supporting POSIX would have version 'Posix' 
> automatically specified in addition to any OS version identifier.  This 
> would be similar to how Windows platforms also have either 'Win32' or 
> 'Win64' defined.  While a good bit of POSIX declarations are indeed 
> implementation dependent, an equally large amount are not, and I believe 
> it would be useful for a version identifier to reflect this.

Having large parts of Posix be implementation dependent kinda shoots the 
whole idea of a standard in the foot.

> As much as I like the version idea, I'm beginning to feel that the C/C++ 
> #ifdef method may actually be preferable in some situations.  For 
> example, some portions of Posix are common and others are not, so I am 
> faced with a few options:
> 
> - Define a separate set of Posix headers for each OS and have the user 
> import the proper set manually.
> 
> - Define a separate set of Posix headers for each OS and do some fancy 
> versioning in a common area to publicly import the proper set 
> automatically.
> 
> - Define a common set of modules, each of which contains version blocks 
> for each OS and may potentially result in multiple declarations of the 
> same symbol occuring in the file (this is what I'm doing now for the 
> Ares Posix headers as it's  the most readable, but I think it may become 
> difficult to deal with when support for more OSes is added)
> 
> - Define a common set of modules with centralized logic for determining 
> various things and use 'static if' in place of 'version' in a manner 
> similar to #ifdef in C/C++
> 
> - Define a common set of modules but specify version identifiers in the 
> makefile or via other means and move the complicated logic out of code 
> and into a configure script or something similar

I suggest another possibility:

- Define a set of modules for each operating system, each in its own package
- Define an "os configuration module" that is edited by the user to 
import the correct os modules

I.e.:
	windows.foo.bar;
	linux.foo.bar;
	bsdunix.foo.bar;

and:

	foo.bar

the contents of foo.bar.d are:

	import windows.foo.bar;
	//import linux.foo.bar;
	//import bsdunix.foo.bar;

No version statements needed.


> While preprocessor logic has proven to be an aboslute nightmare in terms 
> of readability and maintainability in some cases, I truly believe that 
> this is more attributable to a lack of programmer skill than anything 
> else.

Over time, I've been rewriting my use of #ifdef's in C++ to use the D 
style, and the results are worth it.

> Yup, but doing this in every module isn't particularly desirable if such 
> settings may be common for an entire package.

True, but the way to do that is to create an import such as foo.bar 
above that imports or aliases the correct configuration. I think these 
will work out better than the usual C technique of having gobs of 
command line #defines. Just today, I have been having a miserable time 
attempting to compile the Boost test suite, and am being stymied trying 
to figure out which wretched set of #define's have to go on the command 
line just to get the freakin' default to work.

<flame on>
C++ was supposed to reduce the use of the preprocessor. Boost is 
peer-reviewed and written by the best and the brightest C++ developers. 
So why does even the simplest Boost code *heavily* rely on complex, 
obtuse, layer after layer of preprocessor macros?
<flame off>

> I'll admit I'm not 
> entirely sure what the best approach is in this case.  I mentioned the 
> options above mostly in hopes that doing so would help me think through 
> the ideas a bit.

I agree that this has to be thought through very carefully.