www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Conditional compilation inside asm and enum declarations

reply "Julian Salazar" <julian ifeelrandom.com> writes:
Hi, I'm new here to the community but I've been using D for a while now, and 
I have to say that it's a great programming language. I'd like to get 
involved in this community and help shape this language.

I'm just wondering about a minor issue: why are conditional blocks invalid 
within expressions such as enum and asm? I mean, in trivial cases it's fine, 
but in instances where code duplication is a big maintainability nightmare, 
making conditional compilation more flexible would have benefits for 
developers.

Something like (I know it's a trivial example, but you get the point):

asm {
    version(x86) mov EAX, 1;
    else version(x86_64) mov EAX, 2;
}

would trigger an error. Also, though I know enum qualifies as a 
constant/datatype cross, structs and classes are perfectly fine with 
conditional compilation. Couldn't the lexical stuff be changed to support it 
for enum and asm as well?

Also, I noticed that there is no formal specification page for x86-64 inline 
assembly. You define a predefined version identifier such as 
D_InlineAsm_X86_64, but you don't define registers and instructions 
pertaining to it. In GDC for example, using the RAX register in the D inline 
ASM syntax is invalid. Not sure what the case is in LDC (they probably do 
implement it for x86-64), and I know DMD does not have a 64-bit version, but 
the spec should at least have a definition for compilers that do implement 
64-bit support.

Thanks for your time,
- Julian 
Jul 13 2009
next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Jul 13, 2009 at 11:15 AM, Julian Salazar<julian ifeelrandom.com> wr=
ote:
 Hi, I'm new here to the community but I've been using D for a while now, =
and
 I have to say that it's a great programming language. I'd like to get
 involved in this community and help shape this language.
Man, so would I ;)
 I'm just wondering about a minor issue: why are conditional blocks invali=
d
 within expressions such as enum and asm? I mean, in trivial cases it's fi=
ne,
 but in instances where code duplication is a big maintainability nightmar=
e,
 making conditional compilation more flexible would have benefits for
 developers.

 Something like (I know it's a trivial example, but you get the point):

 asm {
 =A0 version(x86) mov EAX, 1;
 =A0 else version(x86_64) mov EAX, 2;
 }

 would trigger an error. Also, though I know enum qualifies as a
 constant/datatype cross, structs and classes are perfectly fine with
 conditional compilation. Couldn't the lexical stuff be changed to support=
it
 for enum and asm as well?
That'd be nice. If you'd like, you could file an enhancement in D's bugzilla, at http://d.puremagic.com/issues/.
 Also, I noticed that there is no formal specification page for x86-64 inl=
ine
 assembly. You define a predefined version identifier such as
 D_InlineAsm_X86_64, but you don't define registers and instructions
 pertaining to it. In GDC for example, using the RAX register in the D inl=
ine
 ASM syntax is invalid. Not sure what the case is in LDC (they probably do
 implement it for x86-64), and I know DMD does not have a 64-bit version, =
but
 the spec should at least have a definition for compilers that do implemen=
t
 64-bit support.
I'm pretty sure LDC does implement x64 inline assembly. It doesn't seem to be documented yet. GDC supports inline assembly for just about any platform but with a nonstandard GCC-based syntax; see the "Extended Assembler" section here: http://dgcc.sourceforge.net/gdc/manual.html I've personally used it for x64 assembly with great success :)
Jul 13 2009
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Julian Salazar wrote:
 Hi, I'm new here to the community but I've been using D for a while now, 
 and I have to say that it's a great programming language. I'd like to 
 get involved in this community and help shape this language.
[snip] Great! This is the place to effect that, and the improvement related to allowing version inside asm blocks is a good start. Andrei
Jul 13 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Julian Salazar wrote:
 Hi, I'm new here to the community but I've been using D for a while now, 
 and I have to say that it's a great programming language. I'd like to 
 get involved in this community and help shape this language.
Welcome!
 I'm just wondering about a minor issue: why are conditional blocks 
 invalid within expressions such as enum and asm? I mean, in trivial 
 cases it's fine, but in instances where code duplication is a big 
 maintainability nightmare, making conditional compilation more flexible 
 would have benefits for developers.
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.
 Something like (I know it's a trivial example, but you get the point):
 
 asm {
    version(x86) mov EAX, 1;
    else version(x86_64) mov EAX, 2;
 }
 
 would trigger an error. Also, though I know enum qualifies as a 
 constant/datatype cross, structs and classes are perfectly fine with 
 conditional compilation. Couldn't the lexical stuff be changed to 
 support it for enum and asm as well?
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. 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.
 Also, I noticed that there is no formal specification page for x86-64 
 inline assembly. You define a predefined version identifier such as 
 D_InlineAsm_X86_64, but you don't define registers and instructions 
 pertaining to it. In GDC for example, using the RAX register in the D 
 inline ASM syntax is invalid. Not sure what the case is in LDC (they 
 probably do implement it for x86-64), and I know DMD does not have a 
 64-bit version, but the spec should at least have a definition for 
 compilers that do implement 64-bit support.
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.
Jul 13 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 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.
That can be done keeping a close look at how LDC has done things. Bye, bearophile
Jul 13 2009
prev sibling next sibling parent reply "Julian Salazar" <julian ifeelrandom.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:h3fu36$22hl$1 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!
Jul 13 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Julian Salazar wrote:
 Maybe it's time for some maintenance? Or a rewrite in a certain 
 higher-level language? ;)
Yes, but to rewrite it requires understanding it, and that means obj2asm.
 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... } )
It's been rehashed here several times (not to rag on you, just to point out that it isn't something that's been overlooked). To sum up, I've worked a lot with both styles - #ifdef, and separating dependencies into independent modules. The latter works a lot better. I know it's hard to believe if you're used to the #ifdef style. I've been doing some work to remove #ifdef's from the dmd compiler source, and the results so far have been very satisfactory.
 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.
For one thing, the valid registers for x86 mode do not include the 64 bit registers. There's also the grammar for the operands, which is not specified in the D spec.
Jul 13 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jul 13, 2009 at 10:05 PM, Walter
Bright<newshound1 digitalmars.com> wrote:
 Julian Salazar wrote:
 It's been rehashed here several times (not to rag on you, just to point out
 that it isn't something that's been overlooked). To sum up, I've worked a
 lot with both styles - #ifdef, and separating dependencies into independent
 modules. The latter works a lot better. I know it's hard to believe if
 you're used to the #ifdef style. I've been doing some work to remove
 #ifdef's from the dmd compiler source, and the results so far have been very
 satisfactory.
But from where I sit it looked like Walter didn't really convince anyone. To me this seems like a point where D is overly patronizing, to use the phrase from a recent post. --bb
Jul 14 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Mon, Jul 13, 2009 at 10:05 PM, Walter
 Bright<newshound1 digitalmars.com> wrote:
 Julian Salazar wrote:
 It's been rehashed here several times (not to rag on you, just to point out
 that it isn't something that's been overlooked). To sum up, I've worked a
 lot with both styles - #ifdef, and separating dependencies into independent
 modules. The latter works a lot better. I know it's hard to believe if
 you're used to the #ifdef style. I've been doing some work to remove
 #ifdef's from the dmd compiler source, and the results so far have been very
 satisfactory.
But from where I sit it looked like Walter didn't really convince anyone. To me this seems like a point where D is overly patronizing, to use the phrase from a recent post.
FWIW I've recently experimented in Phobos with function-level versioning, e.g.: version(Posix) void setenv(in char[] name, in char[] value, bool overwrite) { ... } version(Windows) void setenv(in char[] name, in char[] value, bool overwrite) { ... } Then I have the function right there with all versioned implementations. To me that seems better than Phobos' existing style of version'ing large portions of code, which inevitably results in duplicating a lot of the functionality in two places. One other thing I like about the approach above is that it does not necessitate an extra level of indentation, and it doesn't make you feel guilty for not adding it. I cringe whenever I see at the top level: version (something) { non_indented_stuff more_non_indented_stuff etc } Andrei
Jul 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Then I have the function right there with all versioned implementations. 
 To me that seems better than Phobos' existing style of version'ing large 
 portions of code, which inevitably results in duplicating a lot of the 
 functionality in two places.
I wouldn't consider Phobos to be an exemplary example of how to do versioning, though it should be. I think much of it, like std.file, should be split off into os-dependent "personality" modules, much like the os api modules have been.
Jul 14 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Then I have the function right there with all versioned 
 implementations. To me that seems better than Phobos' existing style 
 of version'ing large portions of code, which inevitably results in 
 duplicating a lot of the functionality in two places.
I wouldn't consider Phobos to be an exemplary example of how to do versioning, though it should be. I think much of it, like std.file, should be split off into os-dependent "personality" modules, much like the os api modules have been.
That would exacerbate code duplication. Consider: version(Windows) void[] read(in char[] name) { ... } version(Posix) void[] read(in char[] name) { ... } S readText(S = string)(in char[] name) { ... } In my approach they are laid as you see them, which I find very well-organized. In your approach you'd define several files each specialized for an OS, which would duplicate readText, or put readText into a common file and have it include platform-specific files. Both solutions are unnecessarily complicated to the simple and clear code above. Andrei
Jul 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Then I have the function right there with all versioned 
 implementations. To me that seems better than Phobos' existing style 
 of version'ing large portions of code, which inevitably results in 
 duplicating a lot of the functionality in two places.
I wouldn't consider Phobos to be an exemplary example of how to do versioning, though it should be. I think much of it, like std.file, should be split off into os-dependent "personality" modules, much like the os api modules have been.
That would exacerbate code duplication. Consider: version(Windows) void[] read(in char[] name) { ... } version(Posix) void[] read(in char[] name) { ... } S readText(S = string)(in char[] name) { ... } In my approach they are laid as you see them, which I find very well-organized.
There is no duplication in: ============ std.file ======================= version (Posix) import std.file.posix; version (Windows) import std.file.windows; /* code common to both goes here, like readText() */ ============================================= that is not also in the layout you described. But there's no hard and fast rule here, and since you are doing the actual work, I defer to your judgment on those cases.
 In your approach you'd define several files each 
 specialized for an OS, which would duplicate readText, or put readText 
 into a common file and have it include platform-specific files. Both 
 solutions are unnecessarily complicated to the simple and clear code above.
While individual details vary, having personality modules for an os offers some nice advantages: 1. It's pretty clear what is happening for each system. 2. An expert on OSA can work on the OSA implementation without risking breaking the OSB implementation for which he had no expertise. 3. By looking at which files changed, you can tell which OS support got updated and which didn't. 4. Porting to a new platform is easier as you've got a list of personality modules that need to be created, rather than version statements threaded through the file contents. 5. The "else" clause in OS version statements tend to be wrong when porting to a new system, meaning that each version has to be gone through manually - overlooking one doesn't always create an obvious error. I think the std.core.sys.* modules illustrate the advantages nicely, especially considering the former kludge-fest bug-ridden way it was done. The core.stdc.stdio still needs some work in this regard, however.
Jul 14 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 In my approach they are laid as you see them, which I find very 
 well-organized.
There is no duplication in:
[snip] I said there's either duplication or complication.
 But there's no hard and fast rule here, and since you are doing the 
 actual work, I defer to your judgment on those cases.
Great, thanks!
 While individual details vary, having personality modules for an os 
 offers some nice advantages:
 
 1. It's pretty clear what is happening for each system.
Not clear to me. It's happened to me more than once to fix a function without knowing that it's version()ed (your fault: you didn't indent it) and that there's a corresponding Windows function some miles away. To me it's much clearer to have all specializations of a given piece of functionality close to one another. They'd naturally tend to converge, not diverge.
 2. An expert on OSA can work on the OSA implementation without risking 
 breaking the OSB implementation for which he had no expertise.
Ok.
 3. By looking at which files changed, you can tell which OS support got 
 updated and which didn't.
I never look... :o)
 4. Porting to a new platform is easier as you've got a list of 
 personality modules that need to be created, rather than version 
 statements threaded through the file contents.
No. This is where your point gets destroyed. Unittests should dictate what must be done for porting to a new platform. Your approach forces either duplicate unittests, or collector files that add clutter.
 5. The "else" clause in OS version statements tend to be wrong when 
 porting to a new system, meaning that each version has to be gone 
 through manually - overlooking one doesn't always create an obvious error.
I try to avoid else. I want to implement setenv on Windows, I prefix it with Windows. I want to implement it on Posix, I prefix it with Posix. Then I write one unittest. Then when a new OS comes, setenv won't be found so the unittest can't run. Problem solved *much* better.
 I think the std.core.sys.* modules illustrate the advantages nicely, 
 especially considering the former kludge-fest bug-ridden way it was 
 done. The core.stdc.stdio still needs some work in this regard, however.
I don't know about that. Andrei
Jul 14 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 1. It's pretty clear what is happening for each system.
Not clear to me. It's happened to me more than once to fix a function without knowing that it's version()ed (your fault: you didn't indent it) and that there's a corresponding Windows function some miles away.
That stuff wasn't in personality modules :-)
 To me it's much clearer to have all specializations of a given piece of 
 functionality close to one another. They'd naturally tend to converge, 
 not diverge.
That works fine initially. Things tend to go awry after a while, though. Take a look at the optlink source. I'm sure it didn't start out that way - the convoluted versioning logic was added layer by layer over many years. If you find large swaths of logic are being duplicated in personality modules, that suggests that the wrong level of abstraction is being used. One of the reasons the FreeBSD port went much faster is I did some refactoring of the abstractions when I did the OSX port.
 4. Porting to a new platform is easier as you've got a list of 
 personality modules that need to be created, rather than version 
 statements threaded through the file contents.
No. This is where your point gets destroyed. Unittests should dictate what must be done for porting to a new platform. Your approach forces either duplicate unittests, or collector files that add clutter.
While I'm a great believer in unittests, I don't agree they are the answer to design problems. They are a supplement, not a replacement. I don't think we're anywhere near 100% Phobos unit test coverage yet. Clutter is always a problem that needs to be continuously reviewed.
 5. The "else" clause in OS version statements tend to be wrong when 
 porting to a new system, meaning that each version has to be gone 
 through manually - overlooking one doesn't always create an obvious 
 error.
I try to avoid else. I want to implement setenv on Windows, I prefix it with Windows. I want to implement it on Posix, I prefix it with Posix. Then I write one unittest. Then when a new OS comes, setenv won't be found so the unittest can't run. Problem solved *much* better.
I agree that the else clause should be avoided for such dependencies, but the damn things tend to creep back in :-( and I'm back to manually grepping for versions and ticking them off one by one. I've done the (initial) port to Linux, I've done the ports to OSX, and FreeBSD. It was easier to port the personality modules than the version statements, especially when they went beyond the trivial. It's been easier to do the same with the compiler source code with the personality modules, too. I've had a very positive experience with it.
Jul 14 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 But from where I sit it looked like Walter didn't really convince
 anyone.  To me this seems like a point where D is overly patronizing,
 to use the phrase from a recent post.
You could argue that, but it also took a long time to convince many about the merit of const and immutable. I understand that C style versioning is so seductive, it's very hard to see what's wrong with it. (For another reason against such, I could send you some of the source to optlink. It's chock full of line by line versioning, nested versioning, a couple dozen version arguments, it's so bad the only way I can tell what's going on is to compile it then *disassemble* it to see what the code actually is.) Contrast that with the dmd front end source where I've made a concerted effort (not 100% yet) to remove #ifdef's. And I didn't even touch on what would have to happen if versioning could slice anywhere - it would have to be done as a separate pre-pass. It couldn't be integrated in to the current one-pass parser, and would do a fine job of screwing up syntax highlighters and pretty-printers much like C's preprocessor can.
Jul 14 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jul 14, 2009 at 10:01 AM, Walter
Bright<newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 But from where I sit it looked like Walter didn't really convince
 anyone. =A0To me this seems like a point where D is overly patronizing,
 to use the phrase from a recent post.
You could argue that, but it also took a long time to convince many about the merit of const and immutable. I understand that C style versioning is=
so
 seductive, it's very hard to see what's wrong with it.

 (For another reason against such, I could send you some of the source to
 optlink. It's chock full of line by line versioning, nested versioning, a
 couple dozen version arguments, it's so bad the only way I can tell what'=
s
 going on is to compile it then *disassemble* it to see what the code
 actually is.)

 Contrast that with the dmd front end source where I've made a concerted
 effort (not 100% yet) to remove #ifdef's.

 And I didn't even touch on what would have to happen if versioning could
 slice anywhere - it would have to be done as a separate pre-pass. It
 couldn't be integrated in to the current one-pass parser, and would do a
 fine job of screwing up syntax highlighters and pretty-printers much like
 C's preprocessor can.
I wasn't very clear. I do think you make a convincing argument that in general lots of micro ifdefs everywhere is not the right approach. But I remain unconvinced that potential for abuse is a good reason to disallow finer scale version() statements. It smacks of the same patronizing one-size-fits-all attitude of java, where everything has to be a class because the designers decided that OO=3D=3Dbetter design. It just doesn't seem to fit well with the rest of the D attitude of not getting in the developer's way. --bb
Jul 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 I do think you make a convincing argument that in general lots of
 micro ifdefs everywhere is not the right approach.
 But I remain unconvinced that potential for abuse is a good reason to
 disallow finer scale version() statements.
It's where the line between micro and fine is that you disagree with, not the principle?
Jul 14 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jul 14, 2009 at 12:04 PM, Walter
Bright<newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 I do think you make a convincing argument that in general lots of
 micro ifdefs everywhere is not the right approach.
 But I remain unconvinced that potential for abuse is a good reason to
 disallow finer scale version() statements.
It's where the line between micro and fine is that you disagree with, not the principle?
Yeh. Like in the case just mentioned -- version() around items in an enum sounds more reasonable to me than having to define the entire enum twice. --bb
Jul 14 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 14 de julio a las 10:01 me escribiste:
 Bill Baxter wrote:
But from where I sit it looked like Walter didn't really convince
anyone.  To me this seems like a point where D is overly patronizing,
to use the phrase from a recent post.
You could argue that, but it also took a long time to convince many about the merit of const and immutable. I understand that C style versioning is so seductive, it's very hard to see what's wrong with it. (For another reason against such, I could send you some of the source to optlink. It's chock full of line by line versioning, nested versioning, a couple dozen version arguments, it's so bad the only way I can tell what's going on is to compile it then *disassemble* it to see what the code actually is.) Contrast that with the dmd front end source where I've made a concerted effort (not 100% yet) to remove #ifdef's. And I didn't even touch on what would have to happen if versioning could slice anywhere - it would have to be done as a separate pre-pass. It couldn't be integrated in to the current one-pass parser, and would do a fine job of screwing up syntax highlighters and pretty-printers much like C's preprocessor can.
I have to debug somebody else code right now and in the name of portability is written in some kind of pseudo-language in C macros. The result is the as optlink, you have to pre-process the source to actually know what it's doing. But I think this is not because C is bad, this is because the people who wrote that code are animals, and I think the language shouldn't get in the way if you want to use it, we all are consenting adults =). I clearly agree with Walter that the right thing to do is separate OS-dependant functionality in different modules, and I think the D standard library should do that as an example of how things should be done in D (showing as a living example that that's the way to go). The same goes for version (!X) ..., I think it should be available, there are cases when the use is valid and you have to do artificial hacks like version (X) else .... It's like Java not having functions or global variable. You're just annoying people that know what they're doing to "protect" the idiots (which can go and use static methods and variables anyways; or version (X) else ...). I completely agree with Bill, that's patronizing... -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Un camión lleno de amigos, míos. Cada uno dando vueltas, en su cabeza. Mientras yo, sufro la picadura de mi propia abeja.
Jul 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 The same goes for version (!X) ..., I think it should be available, there
 are cases when the use is valid and you have to do artificial hacks like
 version (X) else .... It's like Java not having functions or global
 variable. You're just annoying people that know what they're doing to
 "protect" the idiots (which can go and use static methods and variables
 anyways; or version (X) else ...).
It's not about protecting idiots. It's about making the better way to do things the easier and more natural way, and making the worse more difficult. In C++, int a[5]; is the wrong way, and: std::vector<int>(5) a; is the right way. C++ makes the right way ugly and hard. I'd like to reverse that. All languages have some characteristics of "you shouldn't be allowed to do that", the problem is where the line is drawn. I have long, long experience with #ifdef's. I know how convenient it is to just plop those things in, like your first hit of heroin. I know how justifiable just that one little old #ifdef is. Then you add in another, and another, and another, and another, and eventually wonder how you wound up with such an impenetrable thicket of awfulness. My own code gets like that (despite my knowing better) and just about every long lived piece of C/C++/asm code I've run across. I do the same as you, running the preprocessor independently on C code to figure out what's happening. That, however, would be problematic with D as it doesn't have a preprocessor. You'd have to build a separate tool to do it.
Jul 14 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jul 14, 2009 at 2:52 PM, Walter
Bright<newshound1 digitalmars.com> wrote:
 Leandro Lucarella wrote:
 The same goes for version (!X) ..., I think it should be available, ther=
e
 are cases when the use is valid and you have to do artificial hacks like
 version (X) else .... It's like Java not having functions or global
 variable. You're just annoying people that know what they're doing to
 "protect" the idiots (which can go and use static methods and variables
 anyways; or version (X) else ...).
It's not about protecting idiots. It's about making the better way to do things the easier and more natural way, and making the worse more difficu=
lt.
 In C++,

 =A0 int a[5];

 is the wrong way, and:

 =A0 std::vector<int>(5) a;

 is the right way. C++ makes the right way ugly and hard. I'd like to reve=
rse
 that.

 All languages have some characteristics of "you shouldn't be allowed to d=
o
 that", the problem is where the line is drawn.

 I have long, long experience with #ifdef's. I know how convenient it is t=
o
 just plop those things in, like your first hit of heroin. I know how
 justifiable just that one little old #ifdef is. Then you add in another, =
and
 another, and another, and another, and eventually wonder how you wound up
 with such an impenetrable thicket of awfulness. My own code gets like tha=
t
 (despite my knowing better) and just about every long lived piece of
 C/C++/asm code I've run across.
You do realize you're being patronizing, right? "I have so much experience with these things, and I know the right way to write code, and you don't, so I'm not going to give you this thing you request because it's not good for you". Also note that despite D's limitations supposedly making things better, you just got through describing how parts of Phobos turned into a mess anyway. So not only do the little missing capabilities annoy people who would use them judiciously, they also apparently don't have the desired outcome of eliminating poor use of conditional compilation. Sounds like something you would find in a patronizing nanny-language to me. Which is odd, because D isn't like that, overall. --bb
Jul 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 You do realize you're being patronizing, right?  "I have so much
 experience with these things, and I know the right way to write code,
 and you don't, so I'm not going to give you this thing you request
 because it's not good for you".
Sure. There's some of that in every language. They all have some feature or other rejected because the designers, be they individuals or committees, considered such features as encouraging bad practice. Even C++ has this. Why do you think doing | operations on pointers is illegal? It's certainly not a limitation on compiler technology, and there certainly are legitimate uses for it. But the designers felt that was an execrable practice that should be banned. The resumption exception handling model for C++ was rejected because it was felt such encouraged bad practices.
 Also note that despite D's limitations supposedly making things
 better, you just got through describing how parts of Phobos turned
 into a mess anyway.
It's not as good as I would like it to be, but it's also not near as bad with conditional compilation as other libraries I've dealt with.
 So not only do the little missing capabilities annoy people who would
 use them judiciously, they also apparently don't have the desired
 outcome of eliminating poor use of conditional compilation.  Sounds
 like something you would find in a patronizing nanny-language to me.
 Which is odd, because D isn't like that, overall.
Rather than interpret it as patronizing, I ask you to try it my way for a while. Give it a fair shake. Note that D *still has* conditional compilation, and there are no plans to remove it.
Jul 14 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jul 14, 2009 at 5:02 PM, Walter
Bright<newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 You do realize you're being patronizing, right? =A0"I have so much
 experience with these things, and I know the right way to write code,
 and you don't, so I'm not going to give you this thing you request
 because it's not good for you".
Sure. There's some of that in every language. They all have some feature =
or
 other rejected because the designers, be they individuals or committees,
 considered such features as encouraging bad practice.

 Even C++ has this. Why do you think doing | operations on pointers is
 illegal? It's certainly not a limitation on compiler technology, and ther=
e
 certainly are legitimate uses for it. But the designers felt that was an
 execrable practice that should be banned.

 The resumption exception handling model for C++ was rejected because it w=
as
 felt such encouraged bad practices.

 Also note that despite D's limitations supposedly making things
 better, you just got through describing how parts of Phobos turned
 into a mess anyway.
It's not as good as I would like it to be, but it's also not near as bad with conditional compilation as other libraries I've dealt with.
 So not only do the little missing capabilities annoy people who would
 use them judiciously, they also apparently don't have the desired
 outcome of eliminating poor use of conditional compilation. =A0Sounds
 like something you would find in a patronizing nanny-language to me.
 Which is odd, because D isn't like that, overall.
Rather than interpret it as patronizing, I ask you to try it my way for a while. Give it a fair shake.
I think your way is fine. But I also think that there are lots of versions that are binary in nature, like "version(HaveSomeAPI)", where the natural thing to do to supplant the functionality is version(!HaveSomeAPI) { // replacement implementation of SomeAPI goes here } and not version(HaveSomeAPI) {} else { // replacement implementation of SomeAPI goes here } and also not version(HaveSomeAPI) {} else { version =3D HaveNotSomeAPI; } version(HaveNotSomeAPI) { // replacement implementation of SomeAPI goes here } I'm not arguing with you about the big picture of how to organize non-trivial conditional versioning. I'm more arguing that removing ! from version does little to encourage good coding practices and plenty to hinder reasonable ones. Anyway, I don't expect you to change your mind since we've pretty much been over all this before, so I'll leave it be at this. --bb
Jul 14 2009
prev sibling next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Walter Bright wrote:
 It's not about protecting idiots. It's about making the better way to do
 things the easier and more natural way, and making the worse more
 difficult.
Making the better way easy is a worthwhile goal. Making the worse way more difficult is not. A programming language should never set out to intentionally make things difficult for the programmer. A feature that is used in bad code now may eventually find use in new idioms that improve the overall quality of code in the future.
 I have long, long experience with #ifdef's. I know how convenient it is
 to just plop those things in, like your first hit of heroin. I know how
 justifiable just that one little old #ifdef is. Then you add in another,
 and another, and another, and another, and eventually wonder how you
 wound up with such an impenetrable thicket of awfulness. My own code
 gets like that (despite my knowing better) and just about every long
 lived piece of C/C++/asm code I've run across.
When I encounter bad code, I often try to refactor it. The overall trend is that the quality of my code improves over time. -- Rainer Deyke - rainerd eldwood.com
Jul 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Rainer Deyke wrote:
 Walter Bright wrote:
 It's not about protecting idiots. It's about making the better way to do
 things the easier and more natural way, and making the worse more
 difficult.
Making the better way easy is a worthwhile goal. Making the worse way more difficult is not. A programming language should never set out to intentionally make things difficult for the programmer.
Why do C and C++ (and D) make it difficult to do: char *p; p |= 1; ? There's no implementation difficulty in accepting such and generating correct code for it. It's purely a matter of making what is generally considered to be bad practice harder to do. I've never heard anyone argue that this was a bad decision.
 A feature that
 is used in bad code now may eventually find use in new idioms that
 improve the overall quality of code in the future.
#ifdef's have been around for 30 years now. I think that's long enough for them to prove themselves. May I remind everyone that D still does have conditional compilation. It isn't going away.
 I have long, long experience with #ifdef's. I know how convenient it is
 to just plop those things in, like your first hit of heroin. I know how
 justifiable just that one little old #ifdef is. Then you add in another,
 and another, and another, and another, and eventually wonder how you
 wound up with such an impenetrable thicket of awfulness. My own code
 gets like that (despite my knowing better) and just about every long
 lived piece of C/C++/asm code I've run across.
When I encounter bad code, I often try to refactor it. The overall trend is that the quality of my code improves over time.
We all make promises to ourselves to lose weight, too <g>.
Jul 14 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jul 14, 2009 at 5:13 PM, Walter
Bright<newshound1 digitalmars.com> wrote:
 Rainer Deyke wrote:
 Walter Bright wrote:
 It's not about protecting idiots. It's about making the better way to d=
o
 things the easier and more natural way, and making the worse more
 difficult.
Making the better way easy is a worthwhile goal. =A0Making the worse way more difficult is not. =A0A programming language should never set out to intentionally make things difficult for the programmer.
Why do C and C++ (and D) make it difficult to do: =A0 char *p; =A0 p |=3D 1; ? There's no implementation difficulty in accepting such and generating correct code for it. It's purely a matter of making what is generally considered to be bad practice harder to do. I've never heard anyone argue that this was a bad decision.
I've never ever needed to do that, or been the slightest bit tempted to. The operation doesn't make sense. So I think the analogy is inappropos. In contrast, using the negation of a version makes plenty of sense. As does versioning out an entry in an enum that doesn't apply for some reason. ---bb
Jul 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 On Tue, Jul 14, 2009 at 5:13 PM, Walter
 Bright<newshound1 digitalmars.com> wrote:
 Why do C and C++ (and D) make it difficult to do:

   char *p;
   p |= 1;

 ? There's no implementation difficulty in accepting such and generating
 correct code for it. It's purely a matter of making what is generally
 considered to be bad practice harder to do. I've never heard anyone argue
 that this was a bad decision.
I've never ever needed to do that, or been the slightest bit tempted to. The operation doesn't make sense. So I think the analogy is inappropos.
I beg to differ. My C++ compiler implementation of precompiled headers uses bit 0 to determine if a pointer needs to be adjusted based on where it is loaded into memory or not. Using the bottom two bits as flags (because the pointers were aligned) is not all that uncommon. I've seen it done by major companies on some major, very successful projects. Then there's the famous pointer "xor hack".
 In contrast, using the negation of a version makes plenty
 of sense.
As you wrote, we've hashed through that before. Over time, I've eliminated nearly all the negated conditionals from my code, and have been happier with the results. Half of them turned out to be bogus anyway, because I'd add a 3rd state and then latent undetected bugs would appear. Here's one of my faves: #ifndef _WIN32 ... do something for Linux ... #endif Does this happen in reality? I grepped #ifndef's from the Hans Boehm gc: version.h:#ifndef GC_NO_VERSION_VAR allchblk.c:#ifndef USE_MUNMAP alloc.c:#ifndef SMALL_CONFIG AmigaOS.c:#ifndef GC_AMIGA_FASTALLOC AmigaOS.c:#ifndef GC_AMIGA_ONLYFAST AmigaOS.c:#ifndef GC_AMIGA_ONLYFAST AmigaOS.c:#ifndef GC_AMIGA_ONLYFAST AmigaOS.c:#ifndef GC_AMIGA_ONLYFAST AmigaOS.c:#ifndef GC_AMIGA_ONLYFAST AmigaOS.c:#ifndef GC_AMIGA_FASTALLOC AmigaOS.c:#ifndef GC_AMIGA_ONLYFAST dbg_mlc.c:#ifndef SHORT_DBG_HDRS dbg_mlc.c:#ifndef SHORT_DBG_HDRS dbg_mlc.c:#ifndef SHORT_DBG_HDRS dbg_mlc.c:#ifndef SHORT_DBG_HDRS dyn_load.c:#ifndef _sigargs finalize.c:#ifndef NO_DEBUGGING finalize.c:#ifndef JAVA_FINALIZATION_NOT_NEEDED irix_threads.c:#ifndef LINT linux_threads.c:#ifndef __GNUC__ linux_threads.c:#ifndef SIG_THR_RESTART mach_dep.c:#ifndef USE_GENERIC_PUSH_REGS mach_dep.c:#ifndef SPARC mark.c:#ifndef THREADS mark.c:#ifndef UNALIGNED mark.c:#ifndef SMALL_CONFIG mark.c:#ifndef SMALL_CONFIG misc.c:#ifndef _WIN32_WCE misc.c:#ifndef PCR new_hblk.c:#ifndef SMALL_CONFIG os_dep.c:#ifndef HEAP_START os_dep.c:#ifndef THREADS solaris_pthreads.c:#ifndef LINT solaris_threads.c:#ifndef MMAP_STACKS solaris_threads.c:#ifndef LINT The #ifndef NO_DEBUGGING is awful. The #ifndef __GNUC__ means compile for every unknown compiler ever, except gcc. Can't possibly be right. Let's try grepping for !defined. We get: AmigaOS.c:#if !defined(GC_AMIGA_DEF) && !defined(GC_AMIGA_SB) && !defined(GC_AMIGA_DS) && !defined(GC_AMIGA_AM) dyn_load.c:#if !defined(MACOS) && !defined(_WIN32_WCE) dyn_load.c: && !defined(GC_USE_LD_WRAP) dyn_load.c: && !defined(PCR) dyn_load.c:#if !defined(SUNOS4) && !defined(SUNOS5DL) && !defined(IRIX5) && \ dyn_load.c: !defined(MSWIN32) && !defined(MSWINCE) && \ dyn_load.c: !defined(HPUX) && !(defined(LINUX) && defined(__ELF__)) && \ dyn_load.c: !defined(RS6000) && !defined(SCO_ELF) && \ dyn_load.c:#if defined(SUNOS5DL) && !defined(USE_PROC_FOR_LIBRARIES) dyn_load.c:#if defined(SUNOS4) && !defined(USE_PROC_FOR_LIBRARIES) defined(THREADS) dyn_load.c:#if defined(IRIX5) || (defined(USE_PROC_FOR_LIBRARIES) && !defined(LINUX)) !defined(USE_PTHREAD_SPECIFIC) \ linux_threads.c: && !defined(USE_HPUX_TLS) !defined(USE_HPUX_TLS) !defined(USE_PTHREAD_SPECIFIC) \ linux_threads.c: || !defined(__GNUC__) linux_threads.c:#if !defined(HPUX_THREADS) && !defined(GC_OSF1_THREADS) !defined(USE_PTHREAD_SPECIFIC) \ linux_threads.c: && !defined(USE_HPUX_TLS) && !defined(DBG_HDRS_ALL) linux_threads.c:#if !defined(USE_SPIN_LOCK) || defined(PARALLEL_MARK) mach_dep.c:#if defined(__MWERKS__) && !defined(POWERPC) mach_dep.c: && (defined(__MINGW32__) || !defined(MSWIN32)) \ mach_dep.c: && !defined(SCO) && !defined(SCO_ELF) \ mach_dep.c: && !defined(DOS4GW) !defined(__MINGW32__) \ mach_dep.c: && !defined(USE_GENERIC) mach_dep.c:#if defined(ASM_CLEAR_CODE) && !defined(THREADS) mallocx.c:#if defined(THREADS) && !defined(SRC_M3) mark.c:#if !defined(SMALL_CONFIG) && !defined(USE_MARK_BYTES) mark.c: !defined(USE_MARK_BYTES) mark_rts.c:#if !defined(MSWIN32) && !defined(MSWINCE) mark_rts.c: || defined(PCR)) && !defined(SRC_M3) misc.c: || defined(LINUX_THREADS) && !defined(USE_SPIN_LOCK) defined(WIN32_THREADS) \ misc.c:#if !defined(OS2) && !defined(MACOS) && !defined(MSWIN32) && !defined(MSWINCE) misc.c:#if !defined(MSWIN32) && !defined(MSWINCE) && !defined(OS2) && !defined(MACOS) misc.c:#if defined(LINUX) && !defined(SMALL_CONFIG) misc.c:#if !defined(NO_DEBUGGING) !defined(MACOS) \ os_dep.c: && !defined(MSWINCE) defined(HEURISTIC2) !defined(PCR) os_dep.c:#if !defined(NO_EXECUTE_PERMISSION) os_dep.c: && !defined(MSWINCE) \ os_dep.c: && !defined(MACOS) && !defined(DJGPP) && !defined(DOS4GW) os_dep.c:#if defined(PRINTSTATS) && !defined(THREADS) os_dep.c:#if !defined(BEOS) && !defined(AMIGA) && !defined(MSWIN32) \ os_dep.c: && !defined(MSWINCE) && !defined(OS2) os_dep.c: || (defined(LINUX) && defined(SPARC))) && !defined(PCR) !defined(MACOS) \ os_dep.c: && !defined(MACOSX) os_dep.c: && !defined(MSWIN32) && !defined(MSWINCE) \ os_dep.c: && !defined(MACOS) && !defined(DOS4GW) os_dep.c:#if !defined(MSWIN32) && !defined(MSWINCE) defined(ALPHA) || defined(IA64) os_dep.c:#if !defined(MSWIN32) && !defined(MSWINCE) && !defined(LINUX_THREADS) \ os_dep.c: && !defined(GC_USE_LD_WRAP) os_dep.c: (!defined(SMALL_CONFIG) || defined(USE_PROC_FOR_LIBRARIES)) os_dep.c:#if defined(LINUX) && defined(__ELF__) && !defined(SMALL_CONFIG) ptr_chck.c: && !defined(SRC_M3) reclaim.c:#if !defined(SMALL_CONFIG) && defined(USE_MARK_BYTES) reclaim.c:#if !defined(SMALL_CONFIG) && !defined(USE_MARK_BYTES) reclaim.c:#if !defined(SMALL_CONFIG) && !defined(USE_MARK_BYTES) reclaim.c:#if !defined(SMALL_CONFIG) && !defined(USE_MARK_BYTES) reclaim.c:#if !defined(NO_DEBUGGING) stlport is not quite as bad: src\c_locale_win32\c_locale_win32.c:#if !defined (LC_MAX) stlport\stl\_list.c:#if !defined (__WATCOMC__) defined(_STLP_LONG_LONG)&&!defined(__MRC__) //*ty 12/07/2001 - MrCpp can not cast from long long to void* !defined(__MRC__) //*ty 11/24/2001 - MrCpp can not cast from void* to long long stlport\stl\_ostream.c:#if !defined (_STLP_INTERNAL_NUM_PUT_H) stlport\stl\_rope.c:#if !defined (_STLP_USE_NO_IOSTREAMS) stlport\stl\_rope.c:#if defined(__MRC__)||(defined(__SC__) && !defined(__DMC__)) //*TY 05/23/2000 - added support for mpw compiler's trigger function approach to generate vtable !defined(__DMC__)) //*TY 05/23/2000 - added support for mpw compiler's trigger function approach to generate vtable !defined(__DMC__)) //*TY 05/23/2000 - added support for mpw compiler's trigger function approach to generate vtable stlport\stl\_rope.c:#endif /* if !defined (_STLP_USE_NO_IOSTREAMS) */ stlport\stl\_rope.c:#if !defined (_STLP_USE_NO_IOSTREAMS) (_STLP_USE_NATIVE_STRING) stlport\stl\_string_fwd.c:#if !defined ( _STLP_STRING_FWD_C) && ! defined (_STLP_OWN_IOSTREAMS) (defined (_STLP_PTHREADS) || defined (_STLP_UITHREADS) || defined (_STLP_OS2THREADS)) src\c_locale_win32\c_locale_win32.c:#ifndef _LEADBYTE See all those !(NO_FEATURE) constructs? Not no-how, not no-way! And people say my use of goto is bad and should be taken away from me :-) I tried it on the Microsoft Windows api headers. Many pages of very dubious use follow, no need to post it all here. This stuff is marquee showcase code by professional well-paid corporate developers, not idiots or newbies. I slip into writing such crud, too.
 As does versioning out an entry in an enum that doesn't
 apply for some reason.
Can we discuss a real example of this? I think perhaps we can find a way to accommodate the desired result (if not the method) in a clean manner.
Jul 14 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 Using the bottom two bits as flags (because the pointers were aligned) 
 is not all that uncommon. I've seen it done by major companies on some 
 major, very successful projects.
That's done often enough, one or two bits in tagged pointers are useful to implement various data structures (and they are used by garbage collectors too). I even used tagged pointers once in D, using memory allocated from the C heap. Bye, bearophile
Jul 14 2009
prev sibling parent reply grauzone <none example.net> writes:
Walter Bright wrote:
 Bill Baxter wrote:
 On Tue, Jul 14, 2009 at 5:13 PM, Walter
 Bright<newshound1 digitalmars.com> wrote:
 Why do C and C++ (and D) make it difficult to do:

   char *p;
   p |= 1;

 ? There's no implementation difficulty in accepting such and generating
 correct code for it. It's purely a matter of making what is generally
 considered to be bad practice harder to do. I've never heard anyone 
 argue
 that this was a bad decision.
I've never ever needed to do that, or been the slightest bit tempted to. The operation doesn't make sense. So I think the analogy is inappropos.
Often I wanted to write p &= ~3 in low level code. And that does make sense, because it aligns the pointer.
 The #ifndef NO_DEBUGGING is awful. The #ifndef __GNUC__ means compile 
 for every unknown compiler ever, except gcc. Can't possibly be right.
The #ifndef NO_DEBUGGING causes the code to be compiled in debugging mode, if it isn't explicitly deactivated. This is a good thing. I think dmd should compile in debug mode too, and force the user to pass -nodebug to disable it. The #ifndef _GNUC_ is probably for using gcc compiler/libc extensions, which makes sense.
Jul 15 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:
 The #ifndef NO_DEBUGGING causes the code to be compiled in debugging 
 mode, if it isn't explicitly deactivated.
"You, sir, are employing a double negative." -- Mr. Spock It's not that it's impossible to figure out, it's that it's execrable style. In my experience, such constructs correlate strongly with incoherent and buggy code in the sections it appears in, including when I've used it. The interesting question is is the construct itself the cause or the effect of incoherence and bugginess? I'm asking you to give it a chance. Grep your own code for such. See if it could be redone without negation, and see if you like that better. Even so, you *can* use negation in D version statements: version (NO_DEBUGGING) {} else { ... debugging is on ... } they're just a few more characters than laying down a single ! or n. Hopefully, they're enough extra effort that one will minimize the use of them.
Jul 15 2009
parent reply grauzone <none example.net> writes:
 The interesting question is is the construct itself the cause or the 
 effect of incoherence and bugginess?
Maybe. But the real problem is, that you can't force the user to specify either a "yes" or "no" for a specific version/define identifier. He still could just forget about it. Of course, you could always write something like: version (DEBUGGING) { } else version (NODEBUGGING) { } else { static assert(false, "you forgot something!"); } (Or something similar.) But that's a bit annoying.
 Even so, you *can* use negation in D version statements:
 
     version (NO_DEBUGGING) {} else
     {
     ... debugging is on ...
     }
Only marginally better than a #ifndef NO_DEBUGGING.
Jul 15 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
The idea is to make writing garbage more work than doing it right. But 
not make it impossible.
Jul 15 2009
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
grauzone wrote:

 Walter Bright wrote:
 Bill Baxter wrote:
 On Tue, Jul 14, 2009 at 5:13 PM, Walter
 Bright<newshound1 digitalmars.com> wrote:
 Why do C and C++ (and D) make it difficult to do:

   char *p;
   p |= 1;

 ? There's no implementation difficulty in accepting such and generating
 correct code for it. It's purely a matter of making what is generally
 considered to be bad practice harder to do. I've never heard anyone
 argue
 that this was a bad decision.
I've never ever needed to do that, or been the slightest bit tempted to. The operation doesn't make sense. So I think the analogy is inappropos.
Often I wanted to write p &= ~3 in low level code. And that does make sense, because it aligns the pointer.
 The #ifndef NO_DEBUGGING is awful. The #ifndef __GNUC__ means compile
 for every unknown compiler ever, except gcc. Can't possibly be right.
The #ifndef NO_DEBUGGING causes the code to be compiled in debugging mode, if it isn't explicitly deactivated. This is a good thing. I think dmd should compile in debug mode too, and force the user to pass -nodebug to disable it.
So that reads as: if not not actived then if not defined no debugging then do stuff nice!
Jul 15 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Lutger wrote:
 if not not actived then if not defined no debugging then do stuff
Ain't nobody doing nothing around here! Not no how, not no way! No sirree!
Jul 15 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 14 de julio a las 14:52 me escribiste:
 Leandro Lucarella wrote:
The same goes for version (!X) ..., I think it should be available, there
are cases when the use is valid and you have to do artificial hacks like
version (X) else .... It's like Java not having functions or global
variable. You're just annoying people that know what they're doing to
"protect" the idiots (which can go and use static methods and variables
anyways; or version (X) else ...).
It's not about protecting idiots. It's about making the better way to do things the easier and more natural way, and making the worse more difficult. In C++, int a[5]; is the wrong way, and: std::vector<int>(5) a; is the right way. C++ makes the right way ugly and hard. I'd like to reverse that. All languages have some characteristics of "you shouldn't be allowed to do that", the problem is where the line is drawn. I have long, long experience with #ifdef's. I know how convenient it is to just plop those things in, like your first hit of heroin. I know how justifiable just that one little old #ifdef is. Then you add in another, and another, and another, and another, and eventually wonder how you wound up with such an impenetrable thicket of awfulness. My own code gets like that (despite my knowing better) and just about every long lived piece of C/C++/asm code I've run across.
I think you can always use it right when you have only one "#ifdef", and when you see that it's getting messy, you can refactor your code to go the way of "module personalities". If you can do that, the language can scale up *and* down. Otherwise the language is only suitable for big systems. Again, compare it to Java: for big systems is usually a good thing to use an architecture with several layers and OO with very "hard" interfaces. In Java you can only use that, you can't hack a quick script because it doesn't scale down. I think D should handle both worlds gracefully.
 I do the same as you, running the preprocessor independently on C code
 to figure out what's happening. That, however, would be problematic with
 D as it doesn't have a preprocessor. You'd have to build a separate tool
 to do it.
Again, people can make bad code in D anyways, you just make it a little harder, at the expense of making a little harder to use version more flexibly when it's right to do so (as Java make it harder to make a free function or a global variable). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Wenn ist das nunstück git und slotermeyer? Ja! Beiherhund das oder die Flipperwaldt gersput! -- Monty Python (no leer si sabés alemán)
Jul 14 2009
prev sibling parent reply "Julian Salazar" <julian ifeelrandom.com> writes:
I appreciate the reply, and I guess that your point about separating 
dependencies into different modules is a good form of version management. 
I'll still be using the version(x86) asm {...} else version(x86_64) asm 
{...} syntax for a while though. But I'm done arguing that point.

My final question is just about how I would go about contributing to the 
Inline Assembler specification. I found that you generate the language spec 
from the trunk/docsrc folder on the Phobos SVN repo on dsource.org. So, am I 
right to think that I could just download the docsrc folder, edit the 
iasm.dd file (and use the linux.mak file to view it in .html) and submit it 
here for review? 
Jul 14 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Julian Salazar wrote:
 My final question is just about how I would go about contributing to the 
 Inline Assembler specification. I found that you generate the language 
 spec from the trunk/docsrc folder on the Phobos SVN repo on dsource.org. 
 So, am I right to think that I could just download the docsrc folder, 
 edit the iasm.dd file (and use the linux.mak file to view it in .html) 
 and submit it here for review?
Right, except that submitting diffs to bugzilla as an enhancement proposal is the best approach. Newsgroups are for transitory discussions.
Jul 14 2009
prev sibling parent Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Mon, Jul 13, 2009 at 8:24 PM, Walter
Bright<newshound1 digitalmars.com> wrote:
 Julian Salazar wrote:
 Hi, I'm new here to the community but I've been using D for a while now,
 and I have to say that it's a great programming language. I'd like to ge=
t
 involved in this community and help shape this language.
Welcome!
 I'm just wondering about a minor issue: why are conditional blocks inval=
id
 within expressions such as enum and asm? I mean, in trivial cases it's f=
ine,
 but in instances where code duplication is a big maintainability nightma=
re,
 making conditional compilation more flexible would have benefits for
 developers.
The request to do it for enums has been thrashed about before. Essentiall=
y,
 version works at the declaration and statement level, not at the expressi=
on
 level or in between tokens, etc. The reason for this is to encourage a mo=
re
 modular approach to versioning than the typical C method of doing it at t=
he
 lowest level.


 Something like (I know it's a trivial example, but you get the point):

 asm {
 =C2=A0 version(x86) mov EAX, 1;
 =C2=A0 else version(x86_64) mov EAX, 2;
 }

 would trigger an error. Also, though I know enum qualifies as a
 constant/datatype cross, structs and classes are perfectly fine with
 conditional compilation. Couldn't the lexical stuff be changed to suppor=
t it
 for enum and asm as well?
Let me illustrate by a current example. The linker (optlink) is written 1=
00%
 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 h=
ard
 to see what is *actually* being compiled that I'll assemble it, run OBJ2A=
SM
 on the output, and work off of the disassembled code.

 So, in essence, the idea is to push conditional compilation to higher
 levels, not lower levels. Ideally, versioning would be done by abstractin=
g
 all the version differences into an interface implemented by different
 modules.


 Also, I noticed that there is no formal specification page for x86-64
 inline assembly. You define a predefined version identifier such as
 D_InlineAsm_X86_64, but you don't define registers and instructions
 pertaining to it. In GDC for example, using the RAX register in the D in=
line
 ASM syntax is invalid. Not sure what the case is in LDC (they probably d=
o
 implement it for x86-64), and I know DMD does not have a 64-bit version,=
but
 the spec should at least have a definition for compilers that do impleme=
nt
 64-bit support.
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 i=
t.

LDC implements x86-64 inline asm just like x86-32 inline asm, that is
the syntax is the same, and the only real difference is the new 64bit
registers and opcodes.
Of course a spec would be nice, but they're really so similar that it
might well be a single page if you ask me.
Jul 14 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Julian Salazar wrote:
 Hi, I'm new here to the community but I've been using D for a while now, 
 and I have to say that it's a great programming language. I'd like to 
 get involved in this community and help shape this language.
Welcome!
 I'm just wondering about a minor issue: why are conditional blocks 
 invalid within expressions such as enum and asm? I mean, in trivial 
 cases it's fine, but in instances where code duplication is a big 
 maintainability nightmare, making conditional compilation more flexible 
 would have benefits for developers.
 
 Something like (I know it's a trivial example, but you get the point):
 
 asm {
    version(x86) mov EAX, 1;
    else version(x86_64) mov EAX, 2;
 }
 
 would trigger an error. 
A much more convincing example is with position-independent code for Linux shared libraries. In this case you may have a long function, with only a single instruction right in the middle which needs to be changed. This example is taken from my bigint library. In the middle of a 50-line function is this single PIC-dependent instruction: asm { : : adc ECX, EDX; version (D_PIC) {} else { // the next trick can't be done in PIC mode. mov storagenop, EDX; // make #uops in loop a multiple of 3 } mul int ptr [ESP + 8]; : } But I'd class this as a minor annoyance rather than a significant problem.
Jul 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 In this case you may have a long function, with only a single 
 instruction right in the middle which needs to be changed.
void foo() { asm { mov EAX,EAX; ... lots more instructions ... } version (bar) asm { mov EAX,EAX; } asm { ... even more instructions ... mov EAX,EAX; } }
Jul 14 2009
next sibling parent reply Trass3r <mrmocool gmx.de> writes:
Walter Bright schrieb:
 Don wrote:
 In this case you may have a long function, with only a single 
 instruction right in the middle which needs to be changed.
void foo() { asm { mov EAX,EAX; ... lots more instructions ... } version (bar) asm { mov EAX,EAX; } asm { ... even more instructions ... mov EAX,EAX; } }
Man, it's so obvious, yet I wouldn't have hit on that ;)
Jul 14 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Trass3r wrote:
 Man, it's so obvious, yet I wouldn't have hit on that ;)
Most obvious things are obvious only in hindsight <g>.
Jul 14 2009
prev sibling next sibling parent Don <nospam nospam.com> writes:
Walter Bright wrote:
 Don wrote:
 In this case you may have a long function, with only a single 
 instruction right in the middle which needs to be changed.
void foo() { asm { mov EAX,EAX; ... lots more instructions ... } version (bar) asm { mov EAX,EAX; } asm { ... even more instructions ... mov EAX,EAX; } }
Yes, of course, that is what I do. It's ugly, though, especially since you want to _remove_ code for version(bar). asm { ... } version(D_PIC) {} else asm { ... } asm { ... }
Jul 15 2009
prev sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Wed, Jul 15, 2009 at 2:18 AM, Walter
Bright<newshound1 digitalmars.com> wrote:
 Don wrote:
 In this case you may have a long function, with only a single instructio=
n
 right in the middle which needs to be changed.
void foo() { =C2=A0 =C2=A0asm =C2=A0 =C2=A0{ =C2=A0 =C2=A0 =C2=A0 =C2=A0mov EAX,EAX; =C2=A0 =C2=A0 =C2=A0 =C2=A0... lots more instructions ... =C2=A0 =C2=A0} =C2=A0 =C2=A0version (bar) asm =C2=A0 =C2=A0{ =C2=A0 =C2=A0 =C2=A0 =C2=A0mov EAX,EAX; =C2=A0 =C2=A0} =C2=A0 =C2=A0asm =C2=A0 =C2=A0{ =C2=A0 =C2=A0 =C2=A0 =C2=A0... even more instructions ... =C2=A0 =C2=A0 =C2=A0 =C2=A0mov EAX,EAX; =C2=A0 =C2=A0} }
Since when does D guarantee that no code is inserted before/after asm block= s?
Jul 15 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Tomas Lindquist Olsen wrote:
 On Wed, Jul 15, 2009 at 2:18 AM, Walter
 Bright<newshound1 digitalmars.com> wrote:
 Don wrote:
 In this case you may have a long function, with only a single instruction
 right in the middle which needs to be changed.
void foo() { asm { mov EAX,EAX; ... lots more instructions ... } version (bar) asm { mov EAX,EAX; } asm { ... even more instructions ... mov EAX,EAX; } }
Since when does D guarantee that no code is inserted before/after asm blocks?
I think it was around the time that the mail service guaranteed that they wouldn't leave a dead cat in your mailbox on every alternate Wednesday.
Jul 15 2009
next sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Wed, Jul 15, 2009 at 12:24 PM, Daniel
Keep<daniel.keep.lists gmail.com> wrote:
 Tomas Lindquist Olsen wrote:
 On Wed, Jul 15, 2009 at 2:18 AM, Walter
 Bright<newshound1 digitalmars.com> wrote:
 Don wrote:
 In this case you may have a long function, with only a single instruct=
ion
 right in the middle which needs to be changed.
void foo() { =C2=A0 =C2=A0asm =C2=A0 =C2=A0{ =C2=A0 =C2=A0 =C2=A0 =C2=A0mov EAX,EAX; =C2=A0 =C2=A0 =C2=A0 =C2=A0... lots more instructions ... =C2=A0 =C2=A0} =C2=A0 =C2=A0version (bar) asm =C2=A0 =C2=A0{ =C2=A0 =C2=A0 =C2=A0 =C2=A0mov EAX,EAX; =C2=A0 =C2=A0} =C2=A0 =C2=A0asm =C2=A0 =C2=A0{ =C2=A0 =C2=A0 =C2=A0 =C2=A0... even more instructions ... =C2=A0 =C2=A0 =C2=A0 =C2=A0mov EAX,EAX; =C2=A0 =C2=A0} }
Since when does D guarantee that no code is inserted before/after asm bl=
ocks?
 I think it was around the time that the mail service guaranteed that
 they wouldn't leave a dead cat in your mailbox on every alternate Wednesd=
ay.


Funny.

But seriously, it actually takes some effort to make sure all
successive asm statements are merged into a single asm block when
generating code for LLVM.
The DMD frontend "unpacks" asm blocks, so each line is a seperate
AsmStatement, and with version blocks, you have to look into blocks as
well.

LLVM will restore registers etc. when an asm block is done!

And besides this is not in the spec, it might be implied, somehow, but
it's not in the spec.
Jul 15 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Tomas Lindquist Olsen wrote:
 And besides this is not in the spec, it might be implied, somehow, but
 it's not in the spec.
It never occurred to me that this might be necessary, but it obviously is.
Jul 15 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Daniel Keep wrote:
 I think it was around the time that the mail service guaranteed that
 they wouldn't leave a dead cat in your mailbox on every alternate Wednesday.
So that's why my mailbox stinks!
Jul 15 2009