Nachrichten

1

OS-Design / Re: C oder C++

« am: 17. February 2012, 19:21 »

Damit ich verstehe, was passiert, und nicht Code produziere, der nicht tut, weil die Destruktoren, an die ich nicht denken soll, irgendwelche Nebeneffekte haben?

Destruktoren haben üblicherweise keine Nebeneffekte, an die du denken sollst. In keiner gut designten Lib gibt es Dtoren, bei denen du dich um irgendwas kümmern musst.

Die Sprache hat mir gesagt: "Kümmer dich nicht um das Aufräumen, ich mach das". Sie hat damit erstens dafür gesorgt, dass ich nicht drauf aufmerksam werde, weil es implizit passiert, und mir zweitens die Möglichkeit weggenommen, selber in der richtigen Reihenfolge aufzuräumen. Andersrum aufräumen hätte in diesem Beispiel nämlich funktioniert.

Du hast gesagt "Indem man die Objekte umgekehrt zu ihrer Erzeugungsreihenfolge zerstört, kann eben nichts schief gehen." und plötzlich geht eben doch was schief, weil die Sprache meint, schlauer zu sein als der Programmierer.

Nur aus Neugier, wie würde man das richtig machen, wenn man solche Beziehungen hätte? Muss ich die Beziehung erst von Hand brechen bevor ich die Destruktoren laufen lassen kann?

Ach, jetzt verstehe ich das Problem erst. Ziemlich verzwickte Sache. Lösung: Überdenk dein Design, ich glaube nicht, dass das so irgendwie Sinn ergeben würde.

2

OS-Design / Re: C oder C++

« am: 17. February 2012, 18:28 »

Damit ich daran erinnert werde, dass hier was passiert. Dass ich auf einen Blick die möglichen Codepfade sehen kann. Ohne den Code zu kennen und ohne zu wissen, welche anderen Klassen Destruktoren haben.

Ich weiß, meiner Fragerei ist unglaublich nervig, aber es will mir nicht einleuchten. Warum willst du daran erinnert werden, dass da was passiert? Warum willst du auf einen Blick alle möglichen Codepfade sehen?
Du musst nicht wissen, welche anderen Klassen Destruktoren haben.

Hab mal ein bisschen damit rumgespielt (verzeih mir mein C++, ich würde das normal nicht tun):
[...]

Und was soll das jetzt aussagen, außer dass der Programmierer (= du) einen Fehler gemacht hat? Davor kann dich keine Sprache beschützen.

3

OS-Design / Re: C oder C++

« am: 17. February 2012, 17:16 »

Womit auch das Stichwort für das eine wirklich fehlende Feature in C gegeben ist: Richtige Generics. Also der Teil von Templates, den man wirklich braucht. Auf das Berechnung von Primzahlen zur Compilezeit verzichte ich gern.

Nur weil du sowas mit diesen Features machen kannst, heißt das nicht, dass diese schlecht sind. Im Übrigen hat C++11 dafür jetzt sowieso ein neues Sprachfeature, constexpr.

4

OS-Design / Re: C oder C++

« am: 17. February 2012, 17:06 »

Um im Code genau zu sehen, wann was passiert. [...], aber ich will, dass explizit dasteht, was gemacht wird.

Das verstehe ich nicht. Warum willst du das wissen? Wie genau sich das Objekt aufräumt, ist ein Implementierungsdetail, und dass es aufgeräumt wird, garantiert dir der Standard. Wozu willst du das sehen/hinschreiben müssen? Für mich ist das etwas logisch schon implizites, eine Selbstverständlichkeit. Ich würde mich wundern, das hinschreiben zu müssen. Offenbar ist diese Logik noch nicht zu anderen "modernen" OOP-Sprachen durchgedrungen.

Meinetwegen kannst du das in einer hypothetischen Sprache sogar so machen, dass es einen Compilerfehler gibt, wenn ich das Objekt nicht aufräume

Bei Stackobjekten: Okay. Aber wie willst du das bei Objekten am Heap bzw Zeigern auf Objekte lösen? Der Compiler kann nicht wissen, welche Lebenszeit das Ding haben soll. Es kann sogar vorkommen, dass du selbst es nicht weißt, weil es z.B. von äußeren Umständen, wie Spielern auf einem Server abhängt.

Wie gesagt, die Syntax in C++ ist nicht so toll dafür. Zum Beispiel mit Ada sähe das so aus (schnell aus dem Internet zusammenkopiert, weil ich es lang nicht mehr benutzt habe und mit Dateien wohl eh nie was gemacht habe):
[...]

Okay, das ist immerhin schon besser. Aber ich bezweifle, dass diese Fehlerbehandlung in Ada so mächtig ist, wie ein try in anderen Sprachen (Ich kann Ada nicht.). Kann ich damit z.B. nur Fehler in den Zeilen X und Y fangen? Trotzdem: Auch hier kann ich das Freigeben vergessen.

Das kriegt man sich auch nochmal etwas netter formatiert, aber grundsätzlich bist du da syntaktisch schon wieder recht nahe an der expliziten, aber trotzdem übersichtlichen C-Version (da ist halt ein zusätzliches if drin, was auch wieder den möglichen Ablauf genauer klarmacht, aber das könnte man in der hypothetischen Sprache sicher auch noch ein bisschen Syntactic Sugar verpassen):
[...]

Da hier nur eine Resource im Spiel ist, ist alles noch relativ einfach. Sobald es aber mehrere werden, gibts für jede Überprüfung ein if, nur damit der richtige Returncode zurückgegeben wird. Exceptions sind um Welten eleganter, einfacherer und sicherer zu verwenden. (Vorausgesetzt, man hat RAII.)

Und Zeiger/Referenzen können nur im Konstruktor gesetzt werden und nicht irgendwann in der Mitte der Lebenszeit des Objekts? Für mich klingt das nach einem Rezept für subtile Fehler.

Was du mir damit sagen willst, verstehe ich nicht. Es ist ganz natürlich, dass Objekte voneinander abhängen. Indem man die Objekte umgekehrt zu ihrer Erzeugungsreihenfolge zerstört, kann eben nichts schief gehen.

Ich muss es lernen, wenn ich diese Sprache benutzen will.

Jeder Sprache hat ihre Eigenheiten. Außerdem ist das nicht wirklich eine Regel, die viel Lernen bedarf. Meiner Meinung nach ist das eines der logischsten Dinge überhaupt, die man eigentlich gar nicht nachsehen muss.

5

OS-Design / Re: C oder C++

« am: 17. February 2012, 15:48 »

Ich glaube nicht, dass Exceptions wirklich viel ändern. In C hast du stattdessen eben ein goto dastehen, aber gemeinsam haben beide Methoden, dass du irgendwo mittendrin rausspringst. In C hat man halt am Ende irgendein fail:-Label.

Der Unterschied ist: Mit Exceptions muss ich keinen extra Code für die Fehlerbehandlung in Funktionen schreiben, die den Fehler gar nicht behandeln.
Außerdem: Warum willst du einem Objekt explizit sagen müssen, dass es sich aufräumen soll? Wenn es zerstört wird (Sei es automatisch durch verlassen des Scopes, oder durch eine Deallokation über free()/delete), ist die einzig logische Konsequenz, dass Resourcen mitaufgeräumt werden. Warum das also nicht automatisieren?

Genauso kann man in Sprachen mit Exceptions am Funktionsende die Exception fangen, Zeug freigeben und weiterwerfen. In manchen Sprachen wie C++ wäre das syntaktisch nicht so schön, aber das liegt nicht am Konzept.

Au ja. Das führt dann zu tollen try/catch/finally-Konstruktionen. Ein kleines Beispiel in Java:

Code: [Auswählen]

try
{
    mystream.read();
}

finally
{
    try { mystream.close(); } catch(IOException e) {}
}Oder das ganze nochmal auf C++ übertragen (Wir nehmen für einen kurzen Moment an, es gäbe kein RAII):

Code: [Auswählen]

// Exceptions wurden vorher am Stream eingeschaltet

try
{
    char c;
    mystream.read(&c, sizeof c);
}

catch(...)
{
    mystream.close();
    throw;
}Willst du echt sowas schreiben müssen?

Was die Reihenfolge angeht, kann ich mir gut vorstellen, dass das definiert ist, aber kennt diese Definition auch jeder?

Die Reihenfolge ist für den Benutzer irrelephant. Aber ich kann dich beruhigen: Die Reihenfolge ist so intuitiv, wie man sich nur denken kann: Umgekehrt zur Reihenfolge der Erzeugung. Und spätestens, wenn man Variablen hat, die voneinander abhängen (Zeiger/Referenzen aufeinander halten), kann das nur die einzige Möglichkeit sein.
Und wenn dich das immer noch nicht überzeugt: Du musst auch lernen, wie man Variablen benutzt, wie man Funktionen schreibt und dass der Returnwert der Main-Funktion nicht void ist. Sowas gehört zu den Sprachgrundlagen.

6

OS-Design / Re: C oder C++

« am: 17. February 2012, 15:16 »

Dass Destruktoren von Hand aufgerufen werden müssen, ist m.E. kein Bug, sondern ein Feature. Damit sieht man im Code genau den Ablauf von oben nach unten und es passiert nicht noch implizit irgendwelche Magie, die man übersehen könnte, oder von der man wissen müsste, in welcher Reihenfolge sie ausgeführt wird.

C hat ein Problem (nicht): Exceptions. Durch Exceptions entsteht das Problem, dass Routinen zur Freigabe von Resourcen beim Verlassen des Scopes durch eine solche nicht aufgerufen werden. Dieses Problem ist mit RAII in C++ sehr elegangt gelöst.
Das kleinere Problem, welches übrigens auch noch in C vorhanden ist, ist, dass man auf den Aufruf einer Freigabe-Funktion vergessen könnte. Auch das kann in C++ mit RAII nicht passieren.

Was du mit der Magie-Aussage sagen willst, verstehe ich nicht. Da gibt es weder was zu übersehen, noch interessiert da die Reihenfolge. (Die im C++-Standard übrigens exakt festgelegt ist.)