🚀 go-pugleaf

Dietmar Kuehl (kuehl@uzwil.informatik.uni-konstanz.de) wrote:
> Nichts hindert den Compiler daran, DIESEN Aufruf als kritisch anzusehen
> und eine Warnung auszuspucken! ... der Compiler WEISS, dass DIESER
> Aufruf Gefahren in sich birgt. Sicher, wenn 'Clear()' den String nicht
> aendert, wird eine Warnung zuviel ausgegeben. Der beste Weg, diese
> Warnung zu verhindern ist allerdings 'Clear()' zu aendern. In Deinem
> Beispiel kann man die Deklaration von 'Clear()' nicht aendern und man
> sieht also direkt, dass da was faul ist ("undefined behavior" lauert in
> diesem Fall in der Funktion 'Clear()').

Ok, wenn Du das so siehst: Natuerlich hindert den Compiler nichts daran.
Genausogut koennte er bei "if (A = B) {" warnen, das ist letzten Endes eine
Philosophiefrage. Aber: Hast Du mal alte Projekte gewartet, die aus Zeiten
stammen, als die Programmierer nichts von const wussten/wissen wollten?

Das was Du sagst kann man schon so durchgehen lassen - vorausgesetzt ich
schreibe neue Programme und/oder habe einen Arbeitgeber, der beide Augen zu-
drueckt, wenn er meine Stundenabrechnungen unterschreibt. Und der hinter mir
steht, wenn ich meine Deadlines nicht einhalte, weil ich um jeden Pointer
eine Klasse und um jede Funktion, die einen "char*" anstelle eines "const
char*" nimmt eine Wrapper Funktion schreibe. Ich kann mir meine Arbeit
natuerlich beliebig kompliziert machen, nur blaeht das meinen Code auf und
bringt in vielen Faellen wenig bis ueberhaupt nichts fuer die Codequalitaet.

Da Du immer fuer Wrapper Klassen- und Funktionen argumentierst: Hast Du Dir
schonmal ueberlegt, wieviel zusaetzlicher Code in realen Projekten dabei
entsteht? Ist Dir klar, dass jede weitere Zeile Code eine zusaetzliche
Fehlerquelle darstellt? Was glaubst Du, wieviele Programme ich schon gesehen
habe, die Fehler im Code fuer die Fehlerbehandlug enthielten? Witzigerweise
ist dieser Code wesentlich anfaelliger fuer Fehler,

  * weil er weniger getestet wird,

  * weil innerhalb dieses Codes unter Umstaenden bestimmte Mechanismen
    nicht mehr funktionieren, die der Programmierer aus Gewohnheit annimmt
    (Beispiel von vor wenigen Tagen: Der Programmierer prueft, ob der Zeiger
    auf den Kontrollblock gueltig ist. Ist er das nicht, springt er in den
    Fehlerbehandlungszweig und versucht eine Meldung zu loggen. Dummerweise
    vergisst er aber dabei, dass die Routine zum Loggen des Fehlers genau
    diesen Kontrollblock benoetigt und deshalb crasht).

  * weil nicht voraussagbar ist, welche Fehler tatsaechlich auftreten, in
    welcher Reihenfolge und Kombination. Fuer diesen Effekt sind vor allem
    zwei Dinge verantwortlich:

    - Fehler in einer Routine koennen aus fehlerhaftem Code an anderer Stelle
      entstehen. Und Programmierer sind bekanntermassen erfinderisch :-)
    - Reale Programme interagieren mit der Umwelt. Sei es, dass vor dem
      Bildschirm ein Benutzer sitzt, der sich nicht immer so verhaelt, wie
      der Programmierer es erwartet, oder eine Maschine, die auch nicht
      immer das tut, was man erwarten sollte.

> produziert, also z.B.  das Programm mit einen Segmentation-Fault
> abbricht ("abstruerzt"). Das ist schlichtweg katastrophal! Also MUSS

Auch hier bin ich mal wieder nicht Deiner Meinung :-) Ein Segmentation Fault
mit folgendem Code Dump ist in vielen Faellen eine recht vernuenftige Sache,
zumindest in "realen" Programmen, warum steht teilweise schon weiter oben.

Es mag ja sein, dass ich nicht ueber den letzten Schrei in der C++
Entwicklung informiert bin (ich bin der erste, der das zugibt). Aber ich
mache jetzt schon eine geraume Zeit Software und verdiene mein Geld damit.
Und deshalb habe ich auch so meine Erfahrungen. Dazu gehoert:

  * Die Qualitaet der Software haengt nicht von der verwendeten Programmier-
    sprache (wenn man Assembler mal aussen vor laesst). Das heisst gleich-
    zeitig, dass die Qualitaet von Software auch nicht von irgendwelchen
    Sprachkonstrukten abhaengt, die die eine Sprache hat und die andere nicht.

  * Die Qualitaet von Software haengt nicht oder sehr wenig von Regeln zur
    Verwendung/Vermeidung von Sprachkonstrukten ab. Zu diesen Regeln gehoeren
    Dinge wie "Verwende keine gotos", "Verwende keine Pointer", "Das ?:
    Konstrukt ist des Teufels" usw. Die tatsaechlichen Probleme liegen in
    voellig anderen Bereichen, die meist mit Organisation und Planung zu
    tun haben.

  * Komplizierte Sprachfeatures/Bibliotheken werden von den meisten
    Programmierern gemieden. Ein nettes Beispiel aus der letzten Zeit war
    eine Library-Funktion in einer Bibliothek, zu der der Programmierer
    einen Kommentar dazugeschrieben hatte, es gaebe zwar in einem anderen
    Modul jede Menge Funktionen, die sich mit derselben Problemstellung
    herumschlagen wuerden, nur waeren diese so kompliziert, dass er sich
    nicht sicher gewesen sei, dass sie auch das tun, was er wolle, und
    deshalb haette er hier nochmal eine einfach und uebersichtliche Funktion
    hinzugefuegt.
    Wenn es Regeln gibt, solche Features/Bibliotheken trotzdem zu verwenden,
    dann fuehrt das zu qualitativ schlechterem Code. Insofern stehe ich C++
    (und vor allem dem neuen Standard) skeptisch gegenueber. Wenn Du selber
    sagst, man braucht jahrelange Erfahrung um C++ richtig zu benutzen, wie
    finanziere ich dann die Einarbeitung meiner neuen Mitarbeiter? Und
    welche Fehler machen diese, wenn ich sie (gezwungenermassen) in
    Projekten einsetze, wenn sie diese Erfahrung noch nicht haben? Und
    warum soll ich dann ueberhaupt C++ verwenden, wenn die Verwendung
    anderer Sprachen auch keine qualitativ schlechtere Software ergibt?
    Fragen ueber Fragen :-)

Gruss


        Uz


P.S.: Knapp ueber 100 - ich hoffe das geht noch :-)
-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com