"Walter Bright" <newshou...@digitalmars.com> wrote in message
news:h3fu36$22h...@digitalmars.com...
Welcome!
A welcome from the guy who actually created the D language - thanks!
The request to do it for enums has been thrashed about before.
Essentially, version works at the declaration and statement level, not at
the expression level or in between tokens, etc. The reason for this is to
encourage a more modular approach to versioning than the typical C method
of doing it at the lowest level.
That makes sense. I realize that enums aren't structures of data per se, but
simply integers with a range of defined values, which of course should
defined and parsed as one expression. And the comma separator in a list
doesn't lend itself well to being separated by different expressions (in
fact, I recently filed issue 3063 where DSSS goes out-of-memory because of
an extra comma in D2's std.dateparse - not your fault but it'd be nice to
use DSSS again without editing the library source).
Let me illustrate by a current example. The linker (optlink) is written
100% in assembler. This makes it rather intractable. It's also loaded up
with line-by-line nested conditional assembly (and a lot of macros). It's
so hard to see what is *actually* being compiled that I'll assemble it,
run OBJ2ASM on the output, and work off of the disassembled code.
Maybe it's time for some maintenance? Or a rewrite in a certain higher-level
language? ;)
So, in essence, the idea is to push conditional compilation to higher
levels, not lower levels. Ideally, versioning would be done by abstracting
all the version differences into an interface implemented by different
modules.
You make a valid point. However the issue still remains where two versions
for example are inextricably linked. It's understandable that you would keep
separate modules when compiling between architectures like x86 and SPARC64,
or even Basic and Advanced versions (which usually just involve including
functionality). However, when it involves situations such as the x86 &
x86-64 which ARE very similar platforms and a full copy with minimal rewrite
does not seem justified. Tell that to device driver writers with their C,
inline assembly and #ifdefs.
(Side note: I've worked around the versioning with a slightly more
cumbersome syntax.
asm {
...code...
} // But I can't assure that no code is compiled between the two asm
statements =/
version(x86) asm {
...code...
}
else version(x86_64) asm {
...code...
}
)
The first approximation to the definition is to use the Intel asm syntax
as outlined in their processor data sheets. I haven't written a spec more
detailed than that because it's a lot of work and I'm lazy, and such work
is not terribly exciting. But if you'd like to help with that, I'd welcome
it.
How would I go about doing that? It seems like all the work that remains to
be done is just updating opcodes and the valid registers. Maybe a bit of
tightening of the specification and syntax, but other than that the basic
outline is there.
Thanks to everyone for the positive response!
