1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › GnuTLS: Fehlerhafte Zertifikate…
  6. T…

So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: Satan 04.03.14 - 15:19

    Da finde ich die GoTo-Lösung ehrlich gesagt sogar sinnvoller und lesbarer.

    Besonders, wenn sich der long_cleanup_code nur oder hauptsächlich auf Dinge bezieht, die innerhalb der Funktion selbst erzeugt werden. In C++ entspräche das einem try-finally, da schreibt ja wohl auch niemand den eventuellen Cleanup-Code in eine separate Funktion rein...



    1 mal bearbeitet, zuletzt am 04.03.14 15:19 durch Satan.

  2. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: acuntex 04.03.14 - 15:22

    Satan schrieb:
    --------------------------------------------------------------------------------
    > Da finde ich die GoTo-Lösung ehrlich gesagt sogar sinnvoller und lesbarer.
    >
    > Besonders, wenn sich der long_cleanup_code nur oder hauptsächlich auf Dinge
    > bezieht, die innerhalb der Funktion selbst erzeugt werden. In C++
    > entspräche das einem try-finally, da schreibt ja wohl auch niemand den
    > eventuellen Cleanup-Code in eine separate Funktion rein...

    Warum nicht?
    Funktionen sollten nicht ewig lang sein.

    Und komm nicht mit "Funktionsaufrufe sind teuer" - denn try-catch-finally ist ggf. teurer. ;)

  3. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: bstea 04.03.14 - 15:26

    Es geht auch um die Wartbarkeit, nicht alles muss jeden bekannt sein, auch den Programmierer nicht. Da kann eine gekapselte Fehlerbehandlung innerhalb einer Einheit cleverer sein als eine Funktion die evtl. von anderen für andere Zwecke noch "optimiert" wird. Solange es der Lesbarkeit förderlich ist und somit auch der Wartbarkeit, hab ich kein Problem damit. Aber wenn die Logik irgendwann mal portiert werden soll, komm ich mit gotos bspw. in Python nicht recht weit.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  4. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: bernd71 04.03.14 - 15:27

    Aufräumen in eine Funktion delgieren ist aber auch keine schöne Lösungen. Resourcen solten möglichst da freigegeben werden wo sie allokiert werden. Das trägt zur Übersichtlichkeit bei.

  5. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: acuntex 04.03.14 - 15:31

    bernd71 schrieb:
    --------------------------------------------------------------------------------
    > Aufräumen in eine Funktion delgieren ist aber auch keine schöne Lösungen.
    > Resourcen solten möglichst da freigegeben werden wo sie allokiert werden.
    > Das trägt zur Übersichtlichkeit bei.

    Das mag ein Argument in C sein :)

    Ein hoch auf höhere Programmiersprachen wie C++ mit try-catch-finally oder C# mit dem Dispose-Pattern ;-)

  6. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: thomas001le 04.03.14 - 15:32

    In C++ nutzt man RAII und der Destructor räumt auf...darum gibt es auch kein finally in C++ ;-)
    try {} catch(...) { ... throw; } kann man machen, sollte man aber nicht....

  7. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: acuntex 04.03.14 - 15:42

    thomas001le schrieb:
    --------------------------------------------------------------------------------
    > In C++ nutzt man RAII und der Destructor räumt auf...darum gibt es auch
    > kein finally in C++ ;-)
    > try {} catch(...) { ... throw; } kann man machen, sollte man aber nicht....


    Nur aus Interesse: Ist dies mittlerweile mit drin im Standard (und damit in den Compilern) oder muss man immer noch auf boost o.Ä. zurückgreifen?

  8. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: thomas001le 04.03.14 - 15:47

    Was meinst du? Das ist doch alles sogar C++98.

    Man muss natürlich seine Resourcen erst einmal in Klassen gekapselt haben.

  9. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: acuntex 04.03.14 - 15:52

    thomas001le schrieb:
    --------------------------------------------------------------------------------
    > Was meinst du? Das ist doch alles sogar C++98.
    >
    > Man muss natürlich seine Resourcen erst einmal in Klassen gekapselt haben.

    Ich meine smart-pointer, wie von boost (http://www.boost.org/doc/libs/1_55_0/libs/smart_ptr/smart_ptr.htm)
    Dass es selbst geschrieben natürlich funktioniert, ist klar ;)

  10. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: _4ubi_ 04.03.14 - 15:53

    Die Implementierung war IMHO schlecht und wurde nicht gewartet.

  11. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: _4ubi_ 04.03.14 - 15:57

    Ja in C++11, unique_ptr und shared_ptr.

  12. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: Peter Brülls 04.03.14 - 15:57

    MrSpok schrieb:
    --------------------------------------------------------------------------------
    > Fehler macht jeder.
    >
    > Aber sprätestens beim Kompilieren solchen Codes sollte doch wegen
    > "Unreachable code" eine Warnung oder ein Fehler produziert werden.

    Nicht beim gcc

    http://gcc.gnu.org/ml/gcc-help/2011-05/msg00360.html

  13. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: MrSpok 04.03.14 - 16:42

    Peter Brülls schrieb:
    --------------------------------------------------------------------------------
    > Nicht beim gcc
    >
    > gcc.gnu.org

    "In some future release the option will be removed entirely."

    Also statt die Prüfung richtig zu implementieren, schmeißen sie diese Prüfoption ganz raus aus dem Compiler?

    Klingt nach nem Armutszeugnis für GCC.

  14. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: thomas001le 04.03.14 - 16:43

    Wobei es Stimmen gibt, wenn man pointer klassen nimmt und nicht einen neuen container schreibt, macht man etwas falsch ;-)

  15. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: QDOS 04.03.14 - 16:48

    Wer sagt/behauptet sowas?

  16. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: QDOS 04.03.14 - 16:50

    acuntex schrieb:
    --------------------------------------------------------------------------------
    > Ein hoch auf höhere Programmiersprachen wie C++ mit try-catch-finally oder
    > C# mit dem Dispose-Pattern ;-)
    C++ hat kein finally und braucht es dank RAII auch nicht - C# Dispose stinkt im Vergleich zu RAII dann auch noch massiv ab…

  17. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: M.P. 04.03.14 - 17:39

    Hmm,
    jetzt musst Du mir erklären, wie Du in Deinen Programmen ohne if-, switch-, und Schleifen Konstrukte auskommst bzw. diese duch Funktionsaufrufe ersetzen willst ....

  18. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: M.P. 04.03.14 - 17:43

    Stimmt - wahre Informatiker nutzen das hier
    http://de.wikipedia.org/wiki/Brainfuck

  19. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: thomas001le 04.03.14 - 17:55

    Oft wenn man ##c++ fragt ;) Wobei ich auch nicht weiss, wie die dann Polymorphie machen wollen...

  20. Re: So ein Fehler muss doch spätestens beim Kompilieren auffallen ...

    Autor: Themenzersetzer 04.03.14 - 19:35

    Wieso nicht mit oder?

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. wenglor sensoric GmbH, Tettnang
  2. ACP IT Solutions AG, Mainz
  3. Hochschule Furtwangen, Furtwangen
  4. über eTec Consult GmbH, Dreieck Frankfurt - Darmstadt - Hanau

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 19,99€
  2. 12,99€
  3. (u. a. This War of Mine für 4,75€, Children of Morta für 11,99€, Frostpunk für 9,99€, Beat...
  4. (u. a. The Elder Scrolls: Skyrim VR für 26,99€, Wolfenstein 2: The New Colossus für 11€, Prey...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Erörterung zu Tesla-Fabrik: Viel Ärger, wenig Hoffnung
Erörterung zu Tesla-Fabrik
Viel Ärger, wenig Hoffnung

Lässt sich der Bau der Tesla-Fabrik in Grünheide noch stoppen? In einer öffentlichen Erörterung äußerten Anwohner und Umweltschützer ihren Unmut.
Ein Bericht von Friedhelm Greis

  1. Tesla-Fabrik in Grünheide Wasserverband gibt grünes Licht für Giga Berlin
  2. Grünheide Musk besucht erstmals Baustelle für Gigafactory
  3. Gigafactory Musk auf Deutschlandtour in Berlin und Tübingen

Beoplay H95 im Test: Toller Klang, aber für 800 Euro zu schwache ANC-Leistung
Beoplay H95 im Test
Toller Klang, aber für 800 Euro zu schwache ANC-Leistung

Der Beoplay H95 ist ein ANC-Kopfhörer mit einem tollen Klang. Aber wer dafür viel Geld ausgibt, muss sich mit einigen Kompromissen abfinden.
Ein Test von Ingo Pakalski


    Java 15: Sealed Classes - Code-Smell oder moderne Erweiterung?
    Java 15
    Sealed Classes - Code-Smell oder moderne Erweiterung?

    Was bringt das Preview Feature aus Java 15, wie wird es benutzt und bricht das nicht das Prinzip der Kapselung?
    Eine Analyse von Boris Mayer

    1. Java JDK 15 geht mit neuen Features in die General Availability
    2. Java Nicht die Bohne veraltet
    3. JDK Oracle will "Schmerzen" von Java beheben