spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich finde das Thema Glaubhaftigkeit in der Programmierung äußerst kompliziert. Wer sagt mir im Allgemeinen das ich eher einem Fremden aus einen Internetforum trauen kann, als einen Buch was von "Profis" aus der Szene geschrieben und geprüft wurde. Ich hoffe du verstehst auch das Misstrauen meinerseits, denn ich habe für das Ding viel Geld bezahlt (zumindest für einen Studenten )

Ja, ich erkenne es, nicht nur scheinbar sondern vollends, an .

Um es noch einmal zusammen zu fassen: Man benutzt besser Konstruktoren mit Exceptiones statt ein Mix aus Konstruktore und Init-Methoden.

Kann das jemand nochmal kurz begründen?

lg René

Aber ist das nicht oft der Grund, weil es dann einfacher zu veranschaulichen wird? Ist mir zumindest aufgefallen. (bezogen auf BC)

Zitat von »Renegade123«

Um es noch einmal zusammen zu fassen: Man benutzt besser Konstruktoren mit Exceptiones statt ein Mix aus Konstruktore und Init-Methoden.

Kann das jemand nochmal kurz begründen?

Wenn eine Init-Methode fehlschlägt, dann hast Du ein Objekt erzeugt, was Du nicht nutzen kannst. Das Objekt erzeugen und initialisieren ist aber genau die Aufgabe des Konstruktors. Ein erzeugtes Objekt sollte benutzbar sein. Dafür ist es da. Sonst hätte man den Konstruktor auch gleich komplett aus C++ raus lassen können. Er wurde aber zu diesem Zweck eingeführt. Und da ein Konstruktor keinen Wert zurück geben kann, ist eine Ausnahme (Exception) eben genau der richtige Weg. Ein Konstruktor sollte nie fehlschlagen dürfen. Wenn er das tut, dann ist das eine Ausnahme und nicht der Normalfall. Also ist es eine Exception und die sollte man da werfen.

Ähnlich verhält es sich mit vielen anderen Methoden. Sie haben einen Zweck und sollten entweder etwas zurückliefern oder nicht. Wenn sie etwas liefern sollten, dann geht ein Fehlercode nicht. Wenn sie nichts zurückgeben sollte, dann ist die Einführung eines Fehlercodes eine recht unsinnige Art der Verwendung der Methode. Auch hier sind Exceptions sinnvoller. Zudem eine Exception durch alle aufrufenden Methoden hindurch fliegt, bis sie jemand fangen und behandeln kann. Meist kann die aufrufende Methode nämlich mit einem Fehlercode gar nichts anfangen und muss diesen weiter nach oben reichen. Und damit schließt sich wieder der Kreis bezüglich Rückgabewerte. Würde man Fehlercodes verwenden, müsste *jede* Methode Fehlercodes zurückgeben und *jeder* Aufruf müsste geprüft werden. Das kann natürlich nicht Sinn der Sache sein.
Exceptions sind genau dafür da, eine sinnvolle Art und Weise zu bieten, um Fehler zu behandeln und Methoden nicht ihrer sinnvollen Rückgabewerte zu berauben. Auch Void ist übrigens ein sinnvoller Rückgabewert.

Zitat von »Renegade123«

Wer sagt mir im Allgemeinen das ich eher einem Fremden aus einen Internetforum trauen kann, als einen Buch was von "Profis" aus der Szene geschrieben und geprüft wurde.

Dein Misstrauen war und ist zumindest mir absolut verständlich. Ein weiterer Grund, wieso ich Leute gern dazu provoziere, sich selbst die Antworten zu liefern, anstatt zu erwarten, dass sie meine Antworten als gegeben akzeptieren...

Zitat von »Renegade123«

Kann das jemand nochmal kurz begründen?

Kurze Begründung: Weil es genau dafür Konstruktoren gibt...

Lange Antwort: Der Konstruktor wird garantiert immer aufgerufen. Für deine Init Methode gilt das nicht. In manchen Fällen wäre es möglich, das Objekt im Konstruktor in einen Defaultzustand versetzen, in dem es keinen Schaden anrichten kann. Das bedeutet aber auch, dass das Objekt eigentlich zweimal initialisiert wird, die Init Methode ist hier also auch noch unnötig ineffizient. Und spätestens wenn das nicht möglich ist, haben wir es mit einem Objekt zu tun, das sich in einem undefinierten Zustand befindet, in dem die einzige gültige Operation ist, init() aufzurufen. In jedem Fall ist es ein Programmierfehler, zwischen seiner Erzeugung und dem Aufruf der Init Methode irgendetwas mit dem Objekt zu machen. Ich würde sogar argumentieren, dass die erste Variante mit dem ungefährlichen Defaultzustand tatsächlich problematischer ist, denn wenn ich mit diesem Objekt vor init() irgendwas mache, hab ich gar keine Chance, dass mir beim Debuggen alles um die Ohren fliegt und ich so gleich auf den Fehler aufmerksam werde und ihn beheben kann. Aber angenommen der Benutzer macht alles richtig und ruft init() auf. Was passiert, wenn init() fehlschlägt? Dann hab ich hier ein Objekt, dessen Existenz sinnlos ist. Das einzige, was ich durch die Trennung von Konstruktion und Initialisierung gewonnen hab, ist mehr Möglichkeit, etwas falsch zu machen...

Init Methoden sind einfach nur ein Hack, mit dem Leute, die unter dem C Hacker Syndrome leiden, krampfhaft vermeiden wollen, C++ zu programmieren. Ein Workaround mit dem diese Leute versuchen, sich um Sprachmittel, die sie nicht ganz verstanden haben bzw. viel wahrscheinlicher: nicht verstehen wollen, herum zu schleichen.

Zitat von »Renegade123«

Woher kann ich denn bitte offensichtlich wissen, das hinter Synonymen wesentlich besser informierte Programmierer sitzen, wenn man nicht darüber diskutiert?

Naja, du solltest es mal relativ betrachten. Du hast wahrscheinlich kein ausführliches und aktuelles Buch zu C++ gelesen (oder C++ von A bis Z ). Drakon und dot sind Supermoderatoren in dem Forum, das schon viele Jahre existiert und sie haben einige tausend Beiträge. Wenn man etwas aktiv im Forum ist merkt man, dass sie sehr kompetent sind. Ich hoffe, dass ich in den nächsten Jahren selbst mal so gut C++ beherrsche.

Aber ich gebe zu, dass ich etwas überreagiert habe. Bei falschen Empfehlungen sehe ich einfach rot. Ich glaub es kam deswegen zustande, weil du deine Vorposter einfach ignoriert hast. Das nächste mal wäre eine Formulierung wie: "Ich habe aber gelesen, dass ... was sagt ihr dazu?" angebracht.

Zitat von »NachoMan«

Drakon und dot sind Supermoderatoren in dem Forum, das schon viele Jahre existiert und sie haben einige tausend Beiträge. Wenn man etwas aktiv im Forum ist merkt man, dass sie sehr kompetent sind. Ich hoffe, dass ich in den nächsten Jahren selbst mal so gut C++ beherrsche.

Ich fühle mich natürlich geehrt *verbeug*, aber ich denk, ich sollte dazu doch unbedingt sagen, dass die Tatsache, dass unter meinem Namen "Supermoderator" steht (ich empfind den Namen dieses Titels ehrlich gesagt sogar eher als etwas unangenehm, weil er mir ein bisschen selbstherrlich klingt) und ich schon den ein oder anderen Beitrag hier geschrieben hab, mir nicht automatisch Glaubwürdigkeit verleiht. Und ich ermuntere jeden, alles, was ich so von mir gebe, aufs Gründlichste zu hinterfragen...

Zitat von »dot«

Und ich ermuntere jeden, alles, was ich so von mir gebe, aufs Gründlichste zu hinterfragen...

Es liegt doch in der Natur eines guten Programmierers alles zu hinterfragen und am besten auch auszuprobieren.

Zitat von »NachoMan«

Zitat von »dot«

Und ich ermuntere jeden, alles, was ich so von mir gebe, aufs Gründlichste zu hinterfragen...

Es liegt doch in der Natur eines guten Programmierers alles zu hinterfragen und am besten auch auszuprobieren.

exakt

Zitat von »dot«

Und ich ermuntere jeden, alles, was ich so von mir gebe, aufs Gründlichste zu hinterfragen...

dann fange ich doch gleich mal damit an:

Zitat von »dot«

[...], aber ich denk, ich sollte dazu doch unbedingt sagen, dass die Tatsache, dass [...] ich schon den ein oder anderen Beitrag hier geschrieben hab, mir nicht automatisch Glaubwürdigkeit verleiht.

ich habe viele Beiträge geschrieben
ich bin Glaubwürdig
ich kann die Aussage über meine Glaubwürdigkeit bestätigen
und da ich Glaubwürdig bin, ist die Bestätigung der Aussage glaubwürdig
somit dürfte bewiesen sein, dass deine Aussage so nicht stimmt

Zitat

Externes
Originalbild
anzeigen
(Link)