3. switch statt if

switch statt if


  • ...

    0
  • V

    wlefjawef schrieb:

    Ich finde

    bool is_inside = min_x < x && x < max_x && y < min_y && y < max_y;
if(is_inside) { ... }

schöner als 
if(min_x < x && x < max_x && y < min_y && y < max_y) {
    ....
}

    Der compiler optimiert das eh weg.

    Bist Gamecoder?
    Aus jeden Fall setzt Du völlig am falschen Ende an.

    template<frickel>
bool inRange(min,x,max){
   return min<=x && x<=max;
}

if(inRange(min_x,x,max_x) && inRange(min_y,y,max_y)) {
 ... 
}
    0
  • ?

    volkard schrieb:

    template<frickel>
bool inRange(min,x,max){
   return min<=x && x<=max;
}

if(inRange(min_x,x,max_x) && inRange(min_y,y,max_y)) {
 ... 
}

    Swordfish schrieb:

    Ich finde

    template< typename T >
bool is_inside( T value, T min, T max ) { return min < value && value < max; }

if( is_inside( x, min_x, max_x ) && is_inside( y, min_y, max_y ) ) { ... }

    Merkt ihr was? Die Reihenfolge der Argumente ist nicht intuitiv. Besser in ein Range-Objekt kapseln 🤡

    0
  • V

    Ranger schrieb:

    volkard schrieb:

    template<frickel>
bool inRange(min,x,max){
   return min<=x && x<=max;
}

if(inRange(min_x,x,max_x) && inRange(min_y,y,max_y)) {
 ... 
}

    Swordfish schrieb:

    Ich finde

    template< typename T >
bool is_inside( T value, T min, T max ) { return min < value && value < max; }

if( is_inside( x, min_x, max_x ) && is_inside( y, min_y, max_y ) ) { ... }

    Merkt ihr was? Die Reihenfolge der Argumente ist nicht intuitiv. Besser in ein Range-Objekt kapseln 🤡

    Die Funktion heißt eigentlich range(min,x,max) noch von Borlands Zeiten.
    Wäre wohl netter isSorted(min,x,max). Bei isInside erwartet man (x,min,max), jo.

    0
  • ?

    volkard schrieb:

    Die Funktion heißt eigentlich range(min,x,max) noch von Borlands Zeiten.
    Wäre wohl netter isSorted(min,x,max). Bei isInside erwartet man (x,min,max), jo.

    Bei isSorted erwarte ich arg1 <= arg2 <= arg3.
    Bei isInRange erwarte ich arg2 <= arg1 < arg3 (wegen arg1 `isInRange` arg2, arg3)
    Bei isInside kann entweder arg2 < arg1 < arg3 oder arg2 <= arg1 <= arg3 gemeint sein, da muss ich dann jedesmal nachschauen.

    Besser wäre isStrictlyIncreasing (a1 < a2 < a3) und isIncreasing (a1 <= a2 <= a3), aber ich weiss nicht, wie a1 <= a2 < a3 und a1 < a2 <= a3 ausdrücken.

    Deshalb:
    range(a1,a3).contains(a2) => a1 <= a2 < a3
    openRange(a1,a3).contains(a2) => a1 < a2 < a3
    closedRange(a1,a3).contains(a2) => a1 <= a2 <= a3
    leftOpenRange(a1,a3).contains(a2) => a1 < a2 <= a3

    Aber noch klarer ist in diesem Fall das alles auszuschreiben, so wie es war. Vielleicht noch Klammern setzen um die x-Bedingung von der y-Bedingung zu trennen.

    0
  • S

    range(a1,a3).contains(a2) ➡ a1 <= a2 < a3

    Wieso über all rechtsoffene Intervalle als default?
    Edit: Na gut, doofe Frage. 😃

    0
  • ?

    Sone schrieb:

    range(a1,a3).contains(a2) ➡ a1 <= a2 < a3

    Wieso über all rechtsoffene Intervalle als default?
    Edit: Na gut, doofe Frage. 😃

    Du stellst dir diese Frage erst jetzt!?

    Zunächst einmal, wenn man über einen Range iteriert, dann will NIEMAND schreiben

    for (int i=start+1; ...

    d.h es kommen nur a <= b < c oder a <= b <= c in Frage.
    Zweitens, die Länge soll end - start sein und nicht end - start + 1 . Solche +1 oder auch -1 machen Code immer fehleranfälliger.
    Deshalb ist rechtsoffen das einzig wahre.

    Zusätzlich soll bei Arrays die Länge =end und nicht =end-1 sein (wieder das "-1"-Argument), also ist es nur logisch, 0 als ersten Index zu halten.

    0
  • S

    Du stellst dir diese Frage erst jetzt!?

    Nein, die habe ich mir schon vor langer Zeit gestellt und geantwortet. Natürlich passt es viel besser zum Start-End Iteratoren Paar Design, wo man dann auch != nutzen kann, und andere Vorteile...
    Hier aber, ob man Prüft ob eine Zahl in einem Intervall ist, bin ich mir nicht sicher, ob rechtsoffene Intervalle immer noch default sein sollten. Ich würde intuitiv denken, es wird ein geschlossenes Intervall geprüft. Passt aber natürlich zum restlichen, und wenn man ganz akribisch Konsequent ist...

    0
  • ?

    Sone schrieb:

    Hier aber, ob man Prüft ob eine Zahl in einem Intervall ist

    Integer verhalten sich hier gleich wie Iteratoren (man könnte argumentieren Ganzzahlen sind Iteratoren). Und bei Kommazahlen spielt das keine Rolle, von daher passts doch bestens.

    0
  • S

    Integer verhalten sich hier gleich wie Iteratoren (man könnte argumentieren Ganzzahlen sind Iteratoren).

    Schon. Trotzdem - die isInside Funktionen funktionieren auch nur für Random-Access Iteratoren, der Rest stellt keine > o.ä. Operatoren zur Verfügung, daher wäre das auch nicht Übergreifend.

    Für Kommazahlen müsste man ggf. etwas anderes schreiben. Die Kleiner-Gleich Funktionen usw. sind zwar natürlich gefahrlos, dennoch denke ich, man würde vielleicht schon eine Fehlertoleranz einbauen wollen o.ä.

    0
Anmelden zum Antworten