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?

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.

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!

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

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/

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

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

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.

> 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. :-)

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