3. verlassen eines temporary scopes oder try blockes

verlassen eines temporary scopes oder try blockes

  • ?

    Ich hab bei der Variable error einen Denkfehler drinne, aber geht ja ums Prinzip und zeigt gleich einen weiteren Schwachpunkt, wenn man die Rückgabewerte dauernd kontrollieren muss. Da wundert man sich dann, warum die nächste Funktion nicht das tut, was sie soll. Denn sie wird erst gar nicht aufgerufen 😃

    0
  • S

    Meep Meep schrieb:

    nun ja, wenn ein false zurueck gegeben wird ist es kein fehler. daher will ich eigendlich keine exceptions dafuer verwenden. die funktionen die ich da aufrufen muss werfen naemlich bei einem fehler ne exception. true false ist nur dafuer da, damit ich weiß das ich die naechste funktion auch noch aufrufen muss.

    Wieso musst du die naechste Funktion nicht aufrufen wenn eine Funktion false liefert?

    0
  • M

    Shade Of Mine schrieb:

    Meep Meep schrieb:

    nun ja, wenn ein false zurueck gegeben wird ist es kein fehler. daher will ich eigendlich keine exceptions dafuer verwenden. die funktionen die ich da aufrufen muss werfen naemlich bei einem fehler ne exception. true false ist nur dafuer da, damit ich weiß das ich die naechste funktion auch noch aufrufen muss.

    Wieso musst du die naechste Funktion nicht aufrufen wenn eine Funktion false liefert?

    weil wenn z.b. die 5te funktion ein eindeutiges ergebnis liefert, dann gibt sie false zurueck. true wenn ich die naechste funktion aufrufen muss.
    das ergebnis bekomm ich ueber die funktions-parameter zurueck. ist ein recht grosses struct.

    Meep Meep

    0
  • S

    Klingt irgendwie so als waere eine Schleife da recht praktisch.

    0
  • M

    jo ne schleife waere interessant: die funktionen haben aber nicht alle die selbe signatur. koennte man mit nem wrapper bestimmt bereinigen. ich denk mal das das alles zusammen zuviel aufwand wird.
    eigendlich gehts mir jetzt nicht mehr darum wie ich das jetzt schreibe. ich hab es ja so wie ich es brauche.
    es waere nur interessant fuer die zukunft, wenn mal wieder was aehnliches kommt, wie man an die sache richtig heran geht.
    der code im false-zweig ist leider auch nicht immer der selbe. sonst haette ich den schon mal ausgelagert.
    hab grad mal nachgezaehlt: hab 4 von 17 funktionen mit der selben signatur. der rest ist unterschiedlich.

    0
  • C

    Was gefällt dir denn nicht an meiner Variante?

    0
  • M

    cooky451 schrieb:

    Was gefällt dir denn nicht an meiner Variante?

    meinst du das ?

    cooky451 schrieb:

    Ich würde es so machen (wenn umstrukturieren wirklich nicht geht):

    bool b = true;

b && b = f1();
b && b = f2();
b && b = f3();
b && b = f4();
// ...

    ehrlich gesagt versteh ich nicht inwiefern das hilfreich sein soll.

    Meep Meep

    0
  • C

    Es ist doch genau das, was du willst. Die Funktionen werden ausgeführt solange b true ist, ohne dass die Einrückungstiefe immer weiter steigt.

    0
  • M

    hola cooky

    nunja es ist zum teil das was ich moechte.
    ich habe ja ueberall noch eine abfrage fuer false dabei und die ist fast bei jeder funktion anders. was mich auch noch etwas stoert ist das die ueberpruefung fuer jede funktion durchgefuehrt wird, auch wenn ich bei der ersten urberpruefung schon ein false bekommen wuerde.

    Meep Meep

    0
  • P

    Meep Meep schrieb:

    was mich auch noch etwas stoert ist das die ueberpruefung fuer jede funktion durchgefuehrt wird, auch wenn ich bei der ersten urberpruefung schon ein false bekommen wuerde.

    Eben nicht. bei b && blah wird blah nicht mehr ausgewertet, wenn b schon false ist. (google: short circuit evaluation)

    0
  • M

    hab michwohl etwas bloed ausgedrueckt.

    Meep Meep schrieb:

    was mich auch noch etwas stoert ist das die ueberpruefung fuer jede funktion durchgefuehrt wird

    damit meinte ich das fuer jede funktion geprueft wird ob sie ausgefuert werden muss.

    bool b = true;

b && b = f1();
b && b = f2();
b && b = f3();
b && b = f4();

    wenn f1 false zurueck gibt, wird trotzdem noch 3 mal b geprueft. das meinte ich.

    Meep Meep

    0
  • Mod

    Ohne vier Seiten Thread zu lesen (Entschuldigung, wenn ich ganz daneben liege):

    b = b && f1() && f2() && f3() && f4()
    0
  • S

    Meep Meep schrieb:

    wenn f1 false zurueck gibt, wird trotzdem noch 3 mal b geprueft. das meinte ich.

    Nicht zwangsläufig. Der Compiler kann sowas oft optimieren.

    Aber selbst wenn - wo wäre das Problem? b ist ein bool, und der liegt eh schon in einem register. Also kosten sind 0. Und würde mich nicht wundern wenn der Compiler das sogar wegoptimieren könnte.

    0
  • M

    Shade Of Mine schrieb:

    Meep Meep schrieb:

    wenn f1 false zurueck gibt, wird trotzdem noch 3 mal b geprueft. das meinte ich.

    Nicht zwangsläufig. Der Compiler kann sowas oft optimieren.

    Aber selbst wenn - wo wäre das Problem?

    kein problem. vielleicht schafft der compiler es da von wegzuoptimieren. vielleicht aber auch nicht. ist auch nicht wichtig. mir gefaellt es alleine optisch nicht. davon abgesehen das es bei meinem problem nicht dienlich waere

    0
  • K

    Fahr zur Hoelle und benutze goto !

    0
  • Mod

    knivil schrieb:

    Fahr zur Hoelle und benutze goto !

    longjmp direkt aus der Funktion heraus! 🙂

    0
  • M

    knivil schrieb:

    Fahr zur Hoelle und benutze goto !

    geht´s noch ?

    0
  • ?

    Meep Meep schrieb:

    knivil schrieb:

    Fahr zur Hoelle und benutze goto !

    geht´s noch ?

    Ruhig Blut. 🙂
    Das ist nicht so ernst gemeint, wie es klingt...
    http://channel9.msdn.com/achievements/visualstudio/GotoAchievement

    0
Anmelden zum Antworten