magic switch

[André Michelle]

hallo zusammen,


'switch' ist nicht das, was man erwartet, oder ?

Warum werden ab einer erfüllten Bedingung die weiteren cases ausgeführt ? Welche Gründe gibt es für dieses Verhalten ?

var prop = 10;
 
switch ( prop ) {
 
    case 9:
 
        trace ( "9" );
 
    case 10:
 
        trace ( "10" );
 
    case 11:
 
        trace ( "11" ); // 11
 
        break;
 
    case 12:
 
        trace ( "12" ); // nix
 
} 

Das es so ist, wie es ist sehe ich :o)
Aber woher kommt so eine seltsame Interpretation...

[bokel]

Dafür gibt es break.

mfg r.

[André Michelle]

Bokel, du könntest Dir gerne mal die Mühe machen, Beiträge bis zum Ende zu lesen :o)

[emax]

den sinn dieses verhaltens habe ich auch noch nie verstanden.

dafür ist es wesentlich schneller als das if/else if konstrukt.

[bokel]

@emax:
Bei mir ist das if schneller. Das wundert mich allerdings auch, denn ich habe im Hinterkopf, dass beide zum gleichen Bytecode übersetzt werden.

x = 4;
//
t = getTimer();
for (var i = 0; i < 10000; i++) {
    switch (x) {
    case 1 :
        y = 1;
        break;
    case 2 :
        y = 2;
        break;
    case 3 :
        y = 3;
    }
}
trace(getTimer() - t);
//
t = getTimer();
for (var i = 0; i < 10000; i++) {
    if( x == 1) {
        y = 1;
    } else if( x == 2){
        y = 2;
    } else if( x == 3){
        y = 3;
    }
}
trace(getTimer() - t); 

@andre:
Ja, wieso ? Der Grund für dieses Verhalten ist das fehlende break. Oder fragst du nach dem Sinn dieses Verhaltens ?
Der Sinn könnte darin liegen, dass man das Verhalten für verschiedene Fälle nicht immer wieder kopieren muss.

mfg r.

[André Michelle]

@bokel: Genau, es ging mir um den Sinn :o)

Das ist einfach unlogisch und sprachlich nicht nachzuvollziehen.

Für mich muss ein case wahr sein, damit er ausgeführt wird und nicht, wenn ein case vorher wahr war...

[emax]

stimmt, es nimmt sich nix. mal ist if schneller, mal switch.

komisch, habe für die 4gewinnt ki auch benchmarks gemacht
und irgendwie rausgelesen, daß switch schneller wäre.

[bokel]

@andre
Genau dieses Verhalten bekommst du ja mit break hin.

Durch das fehlende break kannst du mehrere Blöcke zu einem zusammenfassen.

switch( x){
    case 1:
    case 8:
    case 13: 
          trace("1, 8, 19");
          break;
    case 4:
          trace("4");
          break;
} 

Wenn es break nicht gäbe, müsstest du den Code vervielfältigen.

switch( x){
    case 1:
          trace("1, 8, 19");
          break;
 
    case 8:
          trace("1, 8, 19");
          break;
 
    case 13: 
          trace("1, 8, 19");
          break;
 
    case 4:
          trace("4");
          break;
} 

Ziemlich unpraktisch.


mfg r.

[André Michelle]

Ja, genau. Ziemlich unpraktisch.
Wann brauche ich den im normalen Leben eine solche Interpretation von 'case' ?

Dein Beispiel überzeugt mich nicht.
Vieleicht liegt es nur daran, dass du es einfach hinnimmst und es benutzt!
Mir kommt es immer ein wenig hoch bei solchen Ungereimtheiten...

[k7c4]

Diese Skripte machen das gleiche

// mit if
if(foo==1)
{
 trace(1)
}
else if(foo==2)
{
trace(2)
}
else if(foo==3)
{
trace(3)
}
else
{
trace("nix")
}
 
// mit switch
switch(foo)
{
case 1: trace(1); break;
case 2: trace(2); break;
case 3: trace(3); break;
default: trace("nix");
} 

ebenso diese beiden Konstrukte

// mit if
if(foo==1)
{
 trace(1)
 trace(2)
 trace(3)
}
else if(foo==2)
{
trace(2)
trace(3)
}
else if(foo==3)
{
trace(3)
}
else
{
trace("nix")
}
 
// mit switch
switch(foo)
{
case 1: trace(1); 
case 2: trace(2); 
case 3: trace(3); break;
default: trace("nix");
} 

Es gibt zwar mehrere Verwendungsmöglichkeiten für ein switch mit break als ohne break, aber wenn man die zweite Möglichkeit mal braucht, dann ist man froh, dass man sie hat.

[bokel]

Dann bedank dich mal bei Kernighan/Ritchie .
Ich schätze switch ist einfach nur ein leicht verkleidetes Assemblerkonstrukt, an dem dann nie mehr jemand was geändert hat (ausser Wirth). Wird eh nur selten benötigt.

Während das Verhalten von break ja noch dokumentiert ist, gibt es noch zwei kleine implemementationsabhängige Fallen, die nicht so offensichtlich sind:

// switch wertet den Ausdruck jedesmal neu aus
function test(){
      trace("test");
      return ++zaehler;
}
 
switch( test()){
       case 100: 
         trace(100);
         break;
       case 200:
           trace(200);
         break;
       case 300:  
         trace(300);     
         break;
}
 
 
// switch benutzt === anstatt == zum Vergleich
x = 1;
 
switch(x){
    case "1": 
        trace("String 1");
        break;
    case 1:
        trace("Number 1");
        break;
} 

Jetzt alle: ärgern, ärgern

mfg r.

[bokel]

@k7c4: Genau, mit break ist man einfach flexibler, ohne dass es mehr kostet.

mfg r.

[André Michelle]

Mag sein. Ich hätte es anders gebraucht, aber das ging eh nicht...

Ich haue es mal hier rein, sollte jemand noch ein paar gute Ideen haben, kann Bokel vieleicht den Thread splitten.

Ich suche einen Ansatz, um in einem 2D Array nach eingeschalteten Bits abzufragen.

Erst das Script dann die Erklärung:

var map = [
 
    [ 1 , 1 , 4 , 5 , 6 , 7 , 8 ],
    [ 1 , 1 , 4 , 5 , 6 , 7 , 8 ],
    [ 1 , 1 , 4 , 5 , 6 , 7 , 8 ],
    [ 1 , 1 , 4 , 133 , 6 , 7 , 8 ],
    [ 1 , 1 , 4 , 5 , 6 , 7 , 8 ]
 
];
 
// ------------------------------------------------------------- //
 
MapManager = function () {};
 
MapManager.initialize = function ( map_data , bit_width ) {
 
    this.map_data = map_data;
 
    this.bit_range = [];
 
    while ( bit_width > -1 ) {
 
        this.bit_range.push ( Math.pow ( 2 , bit_width-- ) );
 
    }
 
}
 
MapManager.accessBit = function ( x , y ) {
 
    trace ( "new request" );
 
    var bit , bit_range , proof_bit;
 
    bit = this.map_data[ y ][ x ];
 
    bit_range = this.bit_range.slice( 0 );
 
    while ( proof_bit = bit_range.pop() ) {
 
        if ( ( bit & proof_bit ) == proof_bit ) {
 
            trace ( "> " + proof_bit + " is on" );
 
        }
 
    }
 
}
 
 
MapManager.initialize ( map , 8 );
 
MapManager.installMethod = function ( obj , method , bit ) {/*Event aufnehmen...*/};
 
MapManager.accessBit ( 3 , 3 );
MapManager.accessBit ( 3 , 1 ); 

Der Witz ist ja bei Tilemap basierten Spielen, dass ich einige Eigenschaften eines Tiles bequem als Bits ein- und ausschalten kann. Dabei können ja auch 2 oder mehr Bits aktiviert sein.
zB. Der Spieler bekommt an einer Stelle Punkte und es weht ein Wind von rechts....

Jetzt suche ich nach einer eleganten Möglichkeit Bits auszulesen.

Bis jetzt mache ich das immer so:

if ( ( bit & 2 ) == 2 ) {
// tue was Bit2 verlangt
} else if ( ( bit & 4 ) == 4 ) {
// tue was Bit4 verlangt
}
etc. 

Das gibt meistens langweilige und schlecht durchschaubare if else Stränge.

Der OOP Ansatz wäre schön, aber auch langsamer.

[bokel]

Wenn du mich fragst, ist das der klassische Fall, in dem OOP schneller als die herkömmliche Programmierung ist. Anstatt einer Menge von Bits würde ich eine Liste von Methoden benutzen, die du dann direkt ausführen kannst. Oder ist die Umwandlung in Funktionen schon so teuer, dass es sich nicht lohnt ?

mfg r.

[k7c4]

Geschrieben von Andre' Michelle
Bis jetzt mache ich das immer so:

if ( ( bit & 2 ) == 2 ) {
// tue was Bit2 verlangt
} else if ( ( bit & 4 ) == 4 ) {
// tue was Bit4 verlangt
}
etc., 

Mach doch so

if ( bit & 2 ) {
// tue was Bit2 verlangt
} else if ( bit & 4 ) {
// tue was Bit3verlangt
}
etc. 

,
denn (bit & 2) kann sowieso nur 2 oder 0 sein ebenso wie bit & 4 nur 4 oder 0 sein kann, und da 0 zu false wird und alles andere zu true...

Oder so, dann weisst Du immer, welches Bit gemeint ist

if ( bit & 1<<1 ) {
// tue was Bit1 verlangt
} else if ( bit & 1<<3 ) {
// tue was Bit3verlangt
}
etc. 

, da wir ja bei Bit0 anfangen zu zählen.

trace(1<<0) //   1 Bit 0
trace(1<<1) //   2 Bit 1
trace(1<<2) //   4 Bit 2
trace(1<<3) //   8 Bit 3
trace(1<<4) //  16 Bit 4
trace(1<<5) //  32 Bit 5
trace(1<<6) //  64 Bit 6
trace(1<<7) // 128 Bit 7 
 

Edit:
Außerdem denke ich, dass Du, wenn Du diese Abfrage so machen willst, Deine Bit-Belegung etwas undurchsichtig/unlogisch angelegt hast, denn normalerweise müsste es so gehen.

if(bit & 1<<0)
{
// bit 0 gesetzt
}
else
{
// bit 0 nicht gesetzt
}
if(bit & 1<<1)
{
// bit 1 gesetzt
}
else
{
// bit 1 nicht gesetzt
}
// etc. 
 

1<<2 wird ja einfach beim Veröffentlichen durch 4 ersetzt