Am 14.03.2014 19:06, schrieb Iain Buclaw:
On 14 March 2014 17:53, Walter Bright <newshou...@digitalmars.com> wrote:
On 3/14/2014 10:26 AM, Johannes Pfau wrote:
I use manifest constants instead of version identifiers as well. If a
version identifier affects the public API/ABI of a library, then the
library and all code using the library always have to be compiled with
the same version switches(inlining and templates make this an even
bigger problem). This is not only inconvenient, it's also easy to think
of examples where the problem will only show up as crashes at runtime.
The only reason why that's not an issue in phobos/druntime is that we
only use compiler defined versions there, but user defined versions are
almost unusable.
Use this method:
--------
import wackyfunctionality;
...
WackyFunction();
--------
module wackyfunctionality;
void WackyFunction() {
version (Linux)
SomeWackyFunction();
else version (OSX)
SomeWackyFunction();
else
... workaround ...
}
--------
Some years down the line (and some platform testing) turns into:
--------
module wackyfunctionality;
void WackyFunction() {
version (Linux) {
version (ARM)
_SomeWackyFunction();
else version (MIPS)
MIPS_SomeWackyFunction();
else version (X86)
SomeWackyFunction();
else version (X86_64)
SomeWackyFunction();
else
... should be some wacky function, but workaround for general case
...
}
else version (OSX) {
version (PPC)
iSomeWackyFunction();
else
SomeWackyFunction(); // In hope there's no other Apple hardware.
}
else version (OpenBSD) {
/// Blah
}
else version (Haiku) {
/// Blah
}
else
... workaround ...
}
--------
That is why the best approach is to have one module per platform
specific code, with a common interface defined in .di file.
Back on my C/C++ days at work, any conditional code would be killed by
me during code reviews.
--
Paulo
