#define SOME_SPECIAL_RESULT true
#define SOME_SPECIAL_RESULT_NOT false

bool some_very_special_condition() {/*...*/}
// ...
switch(some_very_special_condition()) {
    case(SOME_SPECIAL_RESULT): {
        break;
    }
    case(SOME_SPECIAL_RESULT_NOT): {

    }
}

anstatt

if (some_very_special_condition()) {

} else {

}

Die erste Version soll doch nur .. was sein? Besser lesbar? Soll den Code selbsterklärender machen?

Keins von beiden ist gegeben. Es ist (mMn.) viel schlechter Lesbar und macht dazu auch noch den Code unklarer, weil dadurch irgendwie suggeriert wird, dass some_very_special_condition() einen Enumerations-Wert zurückgibt.

Die zweite Version plus ein Kommentar ist doch schön.

Auf welchem Grund würde man sowas machen wollen?

Some people just want to watch the world burn.

Auf welchem Grund würde man sowas machen wollen?

Some people just want to watch the world burn.

Deshalb habe ich die Frage auch so gestellt, wie sie da steht.

------------------------------------------------------------------

EDIT: Mir kam es nur so vor, als würde an dieser einen Stelle, an der ich gerade schraube, ein switch statement mit selbsterklärenden true/false die Lesbarkeit erhöhen. Sieht aber furchtbar aus, wenn ich es mir hier im Forum angucke... hmmm

Für wie schlimm haltet ihr:

#define SOME_SPECIAL_RESULT true
#define SOME_SPECIAL_RESULT_NOT false

bool some_very_special_condition() {/*...*/}
// ...
switch(some_very_special_condition()) {
    case(SOME_SPECIAL_RESULT): {
        break;
    }
    case(SOME_SPECIAL_RESULT_NOT): {
        
    }
}

anstatt

if (some_very_special_condition()) {

} else {

}

Wirklich wirklich schlimm.

const bool ThisSafesTheWorld = some_very_special_condition();

if (ThisSafesTheWorld)
{
}
else
{
}

Das ist zwar eine richtige Lösung, allerdings lohnt sich das Speichern des Wertes nur bei späterer Wiederverwendung.

if (some_very_special_condition())
{
}
else
{
}

jhghjgjh schrieb:

const bool ThisSafesTheWorld = some_very_special_condition();

if (ThisSafesTheWorld)
{
}
else
{
}

Das ist zwar eine richtige Lösung, allerdings lohnt sich das Speichern des Wertes nur bei späterer Wiederverwendung.

if (some_very_special_condition())
{
}
else
{
}

Das optimiert der Compiler raus Es geht ja in diesem Fall darum die Wichtigkeit des Wertes hervorzuheben.

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.

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

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

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.

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.

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

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

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.

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

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.

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.ä.