www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - boolean versioning

reply Mike Parker <aldacron71 yahoo.com> writes:
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
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Mike Parker wrote:

 It would be so, so nice to be able to do something like:
 
 version(VERS_A) || version(VERS_B)
 {
    ...
 }

 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
parent reply Regan Heath <regan netwin.co.nz> writes:
On Fri, 30 Jul 2004 12:55:44 +0100, Stewart Gordon <smjg_1998 yahoo.com> 
wrote:

 Mike Parker wrote:

 It would be so, so nice to be able to do something like:

 version(VERS_A) || version(VERS_B)
 {
    ...
 }

 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) { ... }

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/
Aug 01 2004
next sibling parent reply Sha Chancellor <schancel pacific.net> writes:
In article <opsb2rehyk5a2sq9 digitalmars.com>, Regan Heath says...
On Fri, 30 Jul 2004 12:55:44 +0100, Stewart Gordon <smjg_1998 yahoo.com> 
wrote:

 Mike Parker wrote:

 It would be so, so nice to be able to do something like:

 version(VERS_A) || version(VERS_B)
 {
    ...
 }

 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) { ... }

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

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.
Aug 01 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Sun, 1 Aug 2004 22:41:53 +0000 (UTC), Sha Chancellor 
<schancel pacific.net> wrote:

 In article <opsb2rehyk5a2sq9 digitalmars.com>, Regan Heath says...
 On Fri, 30 Jul 2004 12:55:44 +0100, Stewart Gordon <smjg_1998 yahoo.com>
 wrote:

 Mike Parker wrote:

 It would be so, so nice to be able to do something like:

 version(VERS_A) || version(VERS_B)
 {
    ...
 }

 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) { ... }

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

Why do we need to specify special syntax? Why can't VERSION have pretty much the same rules as IF.

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.
 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
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Regan Heath wrote:
<snip>
 It would be nice to have integer version numbers that we can do 
 comparisons and such things with.


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.
Aug 02 2004
prev sibling parent "Bent Rasmussen" <exo bent-rasmussen.info> writes:
 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
prev sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"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:

 Mike Parker wrote:

 It would be so, so nice to be able to do something like:

 version(VERS_A) || version(VERS_B)
 {
    ...
 }

 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) { ... }

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 &&

This doesn't make sence: in boolean algebra + means || and * is &&(and) So + meaning && is confusing. Sticking with || and && would be best!
 OTOH || and && are well known and understood.

 Regan

 --
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Aug 06 2004
prev sibling parent Sha Chancellor <schancel pacific.net> writes:
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