try



  • exception_defines.h:

    "[...]
    # define try      if (true)
    # define catch(X) if (false)
    [...]"
    

    Ist try nur ein olles Makro, welches anzeigt, dass man mit exceptions arbeitet???



  • Nein, normalerweise wird try/catch vom Standard unterstützt und sollte bewirken, daß im catch-Block die Exceptions aufgefangen und verarbeitet werden. Aber offenbar war da irgendjemand so "schlau", mit diesen Makros die Exception-Behandlung lahmzulegen (btw, woher hast du denn diese Definitionen?).



  • Aus der exception_defines.h in meinem Dev-cpp\includes Ordner.
    Version weiss ich nicht(fremder PC)!



  • Ich habe Version 4.9.9.2!!!



  • Das überrascht mich nicht mehr! 😃



  • Wie, dass ich diese Version habe?^^
    Nene; ist Dev so schlecht???
    Also ich komme damit bestens klar!



  • AGS'ler schrieb:

    # define try      if (true)
    # define catch(X) if (false)
    

    👍

    try
    {
       foo();
    } 
    else
    {
       bar();
    }
    

    😃



  • AGS'ler schrieb:

    Wie, dass ich diese Version habe?^^

    Nee, ich hatte letztens einen Disput. Es ging um die Differenz zwischen dem was ich von der Cpp Laufzeitumgebung in Punkto Benutzerfreundlichkeit erwartet hatte und dem was ich bekommen habe.



  • try und catch sind definitiv keine Makros in C++ sondern ein essenzieller Bestandteil der Sprachnorm. Es sind Schlüsselwörter wie if, class usw.

    Wenn devcpp eine header mit solchen Makros hat, kann C++ nichts dafür! Das ist eine Entscheidung der devcpp-Jungs. Besorgt euch vernünftige Compiler und IDEs, die den C++-Standard vernünftig umsetzen, anstatt irgendwelche Workarounds hier zu posten.



  • da kann ich nur zustimmen.
    diese defines sehen wirklich wenig sinnvoll aus ... wozu braucht man sowas?
    um leute zu verwirren, die das in nem header benutzen und versuchen, exceptions zu behandeln?

    mfg,
    julian



  • Artchi schrieb:

    Besorgt euch vernünftige Compiler und IDEs, die den C++-Standard vernünftig umsetzen, anstatt irgendwelche Workarounds hier zu posten.

    Ja Meister, ich werde gehorchen, wenn du mir einen vernünftigen nennst!!!



  • Visual Studio C++

    -> Kostenlose Express Version. Wie wäre es damit? Für den Anfang 😉

    Bemüh mal Google



  • Oder auch Code::Blocks.



  • AGS'ler schrieb:

    Artchi schrieb:

    Besorgt euch vernünftige Compiler und IDEs, die den C++-Standard vernünftig umsetzen, anstatt irgendwelche Workarounds hier zu posten.

    Ja Meister, ich werde gehorchen, wenn du mir einen vernünftigen nennst!!!

    meinst, mingW ist kein guter compiler?



  • piXelshooter schrieb:

    AGS'ler schrieb:

    Artchi schrieb:

    Besorgt euch vernünftige Compiler und IDEs, die den C++-Standard vernünftig umsetzen, anstatt irgendwelche Workarounds hier zu posten.

    Ja Meister, ich werde gehorchen, wenn du mir einen vernünftigen nennst!!!

    meinst, mingW ist kein guter compiler?

    Nicht in der Version die bei Dev-C++ dabei ist, oder?



  • ist doch die gleiche wie die standalone version? ich hab beide drauf und auf beiden funzt alle s wunderbar...auch exceptions^^

    *edit* auch mingW normal hat diese datei (beide male mingW version 3.4.2)



  • Vermutlich includiert man diese ominöse "exception_defines.h" normalerweise einfach nicht (auch nicht indirekt)? Wäre das vielleicht möglich (ich kenne mingW nicht!)?



  • Julian__ schrieb:

    da kann ich nur zustimmen.
    diese defines sehen wirklich wenig sinnvoll aus ... wozu braucht man sowas?
    um leute zu verwirren, die das in nem header benutzen und versuchen, exceptions zu behandeln?

    Annahme: Mein Programm stürzt nicht ab, weil es Exceptions sauber abarbeitet werden.
    Aber irgendetwas funktioniert nicht ganz wunschgemäß.

    Also einfach mal abschmieren lassen und gdb fragen, wo es geknallt hat. Anschließend weiß man, in welchem try-Block man vielleicht nochmal ran sollte.
    Am einfachsten wäre das, wenn try und catch genauso funktionieren würden, wie es diese Macros beschreiben.

    Wäre jetzt mal meine Idee. Ich gehöre nicht unbedingt zur Fan-Gemeinde der Exceptions, ergo wenig try..catch, ergo kein derartiger Header. Meine Algorithmen müssen so formuliert sein, dass keine Ausnahmen existieren, die man abfangen müsste.



  • @Xin:
    Huh?
    Wie kommst du darauf dass das "entfernen" von try und catch dazu führen würde dass das Programm dort crasht wo irgendein "nicht ganz so wie es sollte" zu finden ist? Klar kann es sein dass das manchmal der Fall ist, aber viele Programme verwenden Exceptions in einigen Fällen die auch beim normalen Arbeiten öfters mal vorkommen können. Wogegen auch nix einzuwenden ist. Wenn die dann nicht dort gefangen werden wo sie gefangen werden sollten geht das Programm u.U. schon VOR dem eigentlichen Problem ganz andere Wege als es gehen sollte.

    Und BTW (nur aus interesse): was für Programme/Algorithmen schreibst du denn dass du ganz auf Exceptions verzichten kannst?

    Dem "wenig try-catch" kann ich mich zwar anschliessen, aber das heisst nicht unbedingt auch "wenig throw". Anders gesagt: in meinen Programmen fange ich auch nicht andauernd irgendwo sinnlos Exceptions, aber es werden an vielen Stellen welche geworfen, einfach weil es so viele Dinge gibt die schief gehen könnten, es aber im Normalfall nicht tun (Speicher anfordern, Files aufmachen, in Files lesen/schreiben, sonstige Resourcen anfordern etc.). "Viel try-catch" ist IMHO ein Hinweis auf den Missbrauch von Exceptions, oder darauf dass jmd. zu faul war Guards zu schreiben. "Wenig throw" dagegen ist IMHO (zumindest in "low-level" Code) ein Hinweis darauf dass jemand zu faul war auf mögliche Fehler zu prüfen und diese entsprechend zu behandeln.



  • Ist das was Xin beschreibt nicht das, was assert macht? (bisschen OT, sry)



  • Also ich stimme 100%-ig mit hustbaer überein!

    PS: Ich liebe dieses Forum!!!


Anmelden zum Antworten