digitalmars.D - boolean versioning
- Mike Parker (34/34) Jul 30 2004 It would be so, so nice to be able to do something like:
- Stewart Gordon (12/23) Jul 30 2004 version(A) version = ABC;
- Regan Heath (14/33) Aug 01 2004 Using || && etc is well known and so might be the best choice, however
- Sha Chancellor (5/41) Aug 01 2004 Why do we need to specify special syntax? Why can't VERSION have pretty...
- Regan Heath (9/61) Aug 01 2004 Like I said above "..just for a change.."
- Stewart Gordon (8/10) Aug 02 2004 We already do.
- Bent Rasmussen (7/10) Aug 02 2004 That's debatable. The version block should tip you off. Its also good to...
- Ivan Senji (5/43) Aug 06 2004 This doesn't make sence: in boolean algebra + means || and * is &&(and)
- Sha Chancellor (5/47) Jul 30 2004 I requested this a bit ago. Versions should be integers and we should
It would be so, so nice to be able to do something like: version(VERS_A) || version(VERS_B) { ... } I'm sure I've seen it mentioned around here before, but I can't recall that there was a final word on it. Where I'm seeing the biggest need for this is with interfacing with existing C libraries. The worst example I can think of is png.h from libpng (which, btw, takes the prize for the most horrendus C header I've ever worked with). It is full of crapola like this: #if defined(PNG_MNG_FEATURES_SUPPORTED) || \ defined(PNG_READ_EMPTY_PLTE_SUPPORTED) || \ defined(PNG_WRITE_EMPTY_PLTE_SUPPORTED) If these were simply wrapping function declarations I could work around it. But the definitions of the two structs one works with the most in libpng are full of these. So it's rather important that the D binding be configurable to sync with custom libpng builds so that one side or the other doesn't attempt to access struct members that aren't there (potentially reading/writing beyond the struct's memory). Unless there's a technique I'm unaware of, the only thing I can see to do in this case is to put in the same stuff for each version: version(A) int x; else version(B) int x; else version(C) int x; else {} This can quickly become even more confusing than it already is from a readability perspective, particularly when there are several fields to declare. So any chance we'll be getting something to solve this in the future? And until then, anything else that can be done as a workaround other than the obvious?
Jul 30 2004
Mike Parker wrote:It would be so, so nice to be able to do something like: version(VERS_A) || version(VERS_B) { ... }<snip>This can quickly become even more confusing than it already is from a readability perspective, particularly when there are several fields to declare. So any chance we'll be getting something to solve this in the future? And until then, anything else that can be done as a workaround other than the obvious?version(A) version = ABC; version(B) version = ABC; version(C) version = ABC; version(ABC) { ... } But maybe you're right, though I'm not sure about the syntax. Maybe version(VERS_A || VERS_B) { ... } Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Jul 30 2004
On Fri, 30 Jul 2004 12:55:44 +0100, Stewart Gordon <smjg_1998 yahoo.com> wrote:Mike Parker wrote:Using || && etc is well known and so might be the best choice, however just for a change how do people think/feel about the following... version(VERS_A , VERS_B) version(VERS_A + VERS_B) Is it obvious what they mean? Did you guess that: ',' replaces || '+' replaces && OTOH || and && are well known and understood. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/It would be so, so nice to be able to do something like: version(VERS_A) || version(VERS_B) { ... }<snip>This can quickly become even more confusing than it already is from a readability perspective, particularly when there are several fields to declare. So any chance we'll be getting something to solve this in the future? And until then, anything else that can be done as a workaround other than the obvious?version(A) version = ABC; version(B) version = ABC; version(C) version = ABC; version(ABC) { ... } But maybe you're right, though I'm not sure about the syntax. Maybe version(VERS_A || VERS_B) { ... }
Aug 01 2004
In article <opsb2rehyk5a2sq9 digitalmars.com>, Regan Heath says...On Fri, 30 Jul 2004 12:55:44 +0100, Stewart Gordon <smjg_1998 yahoo.com> wrote:Why do we need to specify special syntax? Why can't VERSION have pretty much the same rules as IF. Aside from that it can only operate on versions? It would be nice to have integer version numbers that we can do comparisons and such things with.Mike Parker wrote:Using || && etc is well known and so might be the best choice, however just for a change how do people think/feel about the following... version(VERS_A , VERS_B) version(VERS_A + VERS_B) Is it obvious what they mean? Did you guess that: ',' replaces || '+' replaces && OTOH || and && are well known and understood. ReganIt would be so, so nice to be able to do something like: version(VERS_A) || version(VERS_B) { ... }<snip>This can quickly become even more confusing than it already is from a readability perspective, particularly when there are several fields to declare. So any chance we'll be getting something to solve this in the future? And until then, anything else that can be done as a workaround other than the obvious?version(A) version = ABC; version(B) version = ABC; version(C) version = ABC; version(ABC) { ... } But maybe you're right, though I'm not sure about the syntax. Maybe version(VERS_A || VERS_B) { ... }
Aug 01 2004
On Sun, 1 Aug 2004 22:41:53 +0000 (UTC), Sha Chancellor <schancel pacific.net> wrote:In article <opsb2rehyk5a2sq9 digitalmars.com>, Regan Heath says...Like I said above "..just for a change.." Also I kinda thought the fact that it's compile time processing should stand out somehow, if you change the syntax it does, otherwise it's not immediately obvious it happens at compile time rather than runtime.On Fri, 30 Jul 2004 12:55:44 +0100, Stewart Gordon <smjg_1998 yahoo.com> wrote:Why do we need to specify special syntax? Why can't VERSION have pretty much the same rules as IF.Mike Parker wrote:Using || && etc is well known and so might be the best choice, however just for a change how do people think/feel about the following... version(VERS_A , VERS_B) version(VERS_A + VERS_B) Is it obvious what they mean? Did you guess that: ',' replaces || '+' replaces && OTOH || and && are well known and understood. ReganIt would be so, so nice to be able to do something like: version(VERS_A) || version(VERS_B) { ... }<snip>This can quickly become even more confusing than it already is from a readability perspective, particularly when there are several fields to declare. So any chance we'll be getting something to solve this in the future? And until then, anything else that can be done as a workaround other than the obvious?version(A) version = ABC; version(B) version = ABC; version(C) version = ABC; version(ABC) { ... } But maybe you're right, though I'm not sure about the syntax. Maybe version(VERS_A || VERS_B) { ... }Aside from that it can only operate on versions? It would be nice to have integer version numbers that we can do comparisons and such things with.Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 01 2004
Regan Heath wrote: <snip>We already do. A block of version(42) is compiled in iff a version >= 42 is set. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.It would be nice to have integer version numbers that we can do comparisons and such things with.
Aug 02 2004
Also I kinda thought the fact that it's compile time processing should stand out somehow, if you change the syntax it does, otherwise it's not immediately obvious it happens at compile time rather than runtime.That's debatable. The version block should tip you off. Its also good to be able to use the same syntax in a different context if it means the same thing, i.e. true || false. I prefer the conventional logic symbols (^, v, ...), but some weight is placed on conformance with the C/C++ heritage and besides it would probably require some special keyboards to make it pleasant to use. I also don't want to bet money on that the QWERTY layout will be fixed in the near future. OTOH my keyboard does have a stop button. :-)
Aug 02 2004
"Regan Heath" <regan netwin.co.nz> wrote in message news:opsb2rehyk5a2sq9 digitalmars.com...On Fri, 30 Jul 2004 12:55:44 +0100, Stewart Gordon <smjg_1998 yahoo.com> wrote:This doesn't make sence: in boolean algebra + means || and * is &&(and) So + meaning && is confusing. Sticking with || and && would be best!Mike Parker wrote:Using || && etc is well known and so might be the best choice, however just for a change how do people think/feel about the following... version(VERS_A , VERS_B) version(VERS_A + VERS_B) Is it obvious what they mean? Did you guess that: ',' replaces || '+' replaces &&It would be so, so nice to be able to do something like: version(VERS_A) || version(VERS_B) { ... }<snip>This can quickly become even more confusing than it already is from a readability perspective, particularly when there are several fields to declare. So any chance we'll be getting something to solve this in the future? And until then, anything else that can be done as a workaround other than the obvious?version(A) version = ABC; version(B) version = ABC; version(C) version = ABC; version(ABC) { ... } But maybe you're right, though I'm not sure about the syntax. Maybe version(VERS_A || VERS_B) { ... }OTOH || and && are well known and understood. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 06 2004
In article <cedchm$2h41$1 digitaldaemon.com>, Mike Parker <aldacron71 yahoo.com> wrote:It would be so, so nice to be able to do something like: version(VERS_A) || version(VERS_B) { ... } I'm sure I've seen it mentioned around here before, but I can't recall that there was a final word on it. Where I'm seeing the biggest need for this is with interfacing with existing C libraries. The worst example I can think of is png.h from libpng (which, btw, takes the prize for the most horrendus C header I've ever worked with). It is full of crapola like this: #if defined(PNG_MNG_FEATURES_SUPPORTED) || \ defined(PNG_READ_EMPTY_PLTE_SUPPORTED) || \ defined(PNG_WRITE_EMPTY_PLTE_SUPPORTED) If these were simply wrapping function declarations I could work around it. But the definitions of the two structs one works with the most in libpng are full of these. So it's rather important that the D binding be configurable to sync with custom libpng builds so that one side or the other doesn't attempt to access struct members that aren't there (potentially reading/writing beyond the struct's memory). Unless there's a technique I'm unaware of, the only thing I can see to do in this case is to put in the same stuff for each version: version(A) int x; else version(B) int x; else version(C) int x; else {} This can quickly become even more confusing than it already is from a readability perspective, particularly when there are several fields to declare. So any chance we'll be getting something to solve this in the future? And until then, anything else that can be done as a workaround other than the obvious?I requested this a bit ago. Versions should be integers and we should be able to do everything we can with an integer in an 'if' statement, but with them in a version statement!
Jul 30 2004