www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - switch with non int non string

reply Kevin Bealer <Kevin_member pathlink.com> writes:
Why is the switch statement restricted to int-like and char[]?  If there is no
compile-time switch code available, it should be easy enough to devolve the
switch to an if/then/else style expression, right?

Kevin
May 19 2004
next sibling parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c8gf5i$4v9$1 digitaldaemon.com>, Kevin Bealer says...

Why is the switch statement restricted to int-like and char[]?  If there is no
compile-time switch code available, it should be easy enough to devolve the
switch to an if/then/else style expression, right?

Kevin


I should be more elaborate when I post:  what I mean is to allow arbitrary
object comparison, not just the integer and string cases where lookup can be
accelerated easily.

Also, static or even on-the-fly constructed objects for the comparisons.  If it
works as a hash table, great, otherwise, if-then-else is built.  Some compilers
will work harder at generating fast searches.

class range_test {
    int _x, _y;
    this(int x, int y)
    {
        _x = x; _y = y;
    }
May 19 2004
parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c8h5au$1fkb$1 digitaldaemon.com>, Kevin Bealer says...

In article <c8gf5i$4v9$1 digitaldaemon.com>, Kevin Bealer says...

Why is the switch statement restricted to int-like and char[]?  If there is no
compile-time switch code available, it should be easy enough to devolve the
switch to an if/then/else style expression, right?

Kevin




(that got truncated, ill try again..)

I should be more elaborate when I post:  what I mean is to allow arbitrary
object comparison, not just the integer and string cases where lookup can be
accelerated easily.

Also, static or even on-the-fly constructed objects for the comparisons.  If it
works as a hash table, great, otherwise, if-then-else is built.  Some compilers
will work harder at generating fast searches.

class range_test {
int _x, _y;
this(int x, int y)
{
_x = x; _y = y;
}

int opCmp(int q)
{
if (q <= x) return -1;
if (q >= y) return 1;
return 0;
}
};

void code(int x)
{
static range set1(0,10);
static range set2(11,20);
static range set1(90,100);

switch(x) {
case set1: /+ handle 0-10 +/ break;
case set2: /+etc+/ break;
case set3: /+etc+/ break;
case 72:
case 33:
case 357:
/+ something else +/
break;
}
}

All of which is possible if switches - or parts of switches - can be runtime
features.  In some cases, the compiler can do fancy accelerations, other times
not, but in all cases, syntax is expressive and clean (if you like "switch".)

Consider all the code that looks like:

switch(x) {
//... many static cases...

default:
if (isalpha(x)) {
} else if (isnum(x)) {
//...
} else ... {
}
}

Kevin
May 19 2004
parent reply Roel Mathys <roel.mathys yucom.be> writes:
Kevin Bealer wrote:


 
 void code(int x)
 {
 static range set1(0,10);
 static range set2(11,20);
 static range set1(90,100);
 
 switch(x) {
 case set1: /+ handle 0-10 +/ break;
 case set2: /+etc+/ break;
 case set3: /+etc+/ break;
 case 72:
 case 33:
 case 357:
 /+ something else +/
 break;
 }
 }
 


how do you plan to tackle overlapping intervals,
e.g.:

static range set1(0,100); // I changed this
static range set2(11,20);
static range set3(90,100);

instead of your original code,

this would mean "case set1: ...; break;" is executed and set2, and set3 
cases never.

regards,
roel
May 20 2004
parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c8hsu7$2jqj$1 digitaldaemon.com>, Roel Mathys says...

Kevin Bealer wrote:


 
 void code(int x)
 {
 static range set1(0,10);
 static range set2(11,20);
 static range set1(90,100);
 
 switch(x) {
 case set1: /+ handle 0-10 +/ break;
 case set2: /+etc+/ break;
 case set3: /+etc+/ break;
 case 72:
 case 33:
 case 357:
 /+ something else +/
 break;
 }
 }
 


how do you plan to tackle overlapping intervals,
e.g.:

static range set1(0,100); // I changed this
static range set2(11,20);
static range set3(90,100);

instead of your original code,

this would mean "case set1: ...; break;" is executed and set2, and set3 
cases never.

regards,
roel


I didn't really plan, but I would expect that a simple decision could be made,
i.e. take the first match.  It works that way now, but only because the values
must be unique.

So for a switch like:

switch(x) {
case 10: A(); break;
case 20: B(); break;
case 30: C(); break;
case range(25,40): D(); break;
case phil: E(); /* where phil is a variable */
case 99:  X(); break;
case 101: Y(); break;
case 203: Z(); break;
};

.. Would potentially use an optimized switching technique to decide between the
first three, then use "==" to decide the range and variable, then possibly
another optimized table for the last set.

This is clean and readable, and still affords optimization in cases where it
doesn't affect determinism.  Determinism is critical for robustness.  When speed
is important the coder would organize the list accordingly.  But picking 203
from a table before checking (x == phil) would be illegal.

The simplest implementation would devolve the switch into runs of compile time
pieces and if-then-else pieces (with "goto"s as needed for fall through), then
compile with current techniques.

But in most cases, (x == some_obj) will inline into x.q == some_obj.q, which
after register-izing variables, will become a static switch test.  When we
define equality for an operator, it usually compares against one or more
internal primitives.

Kevin
May 21 2004
prev sibling next sibling parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c8gf5i$4v9$1 digitaldaemon.com>, Kevin Bealer says...

Why is the switch statement restricted to int-like and char[]?  If there is no
compile-time switch code available, it should be easy enough to devolve the
switch to an if/then/else style expression, right?

Kevin


I should be more elaborate when I post:  what I mean is to allow arbitrary
object comparison, not just the integer and string cases where lookup can be
accelerated easily.

Also, static or even on-the-fly constructed objects for the comparisons.  If it
works as a hash table, great, otherwise, if-then-else is built.  Some compilers
will work harder at generating fast searches.

class range_test {
    int _x, _y;
    this(int x, int y)
    {
        _x = x; _y = y;
    }
May 19 2004
prev sibling parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c8gf5i$4v9$1 digitaldaemon.com>, Kevin Bealer says...

Why is the switch statement restricted to int-like and char[]?  If there is no
compile-time switch code available, it should be easy enough to devolve the
switch to an if/then/else style expression, right?

Kevin


I should be more elaborate when I post:  what I mean is to allow arbitrary
object comparison, not just the integer and string cases where lookup can be
accelerated easily.

Also, static or even on-the-fly constructed objects for the comparisons.  If it
works as a hash table, great, otherwise, if-then-else is built.  Some compilers
will work harder at generating fast searches.

class range_test {
    int _x, _y;
    this(int x, int y)
    {
        _x = x; _y = y;
    }
May 19 2004