Diskussion:Konstruktoren und Destruktoren

message: Es wäre wichtig wenn dastünde auf welche Programmiersprache sich die Beispiele beziehen. Ich vermute mal es ist C#.
"Object( int value1 ) : this( value, 0 )"
Müsste hier hinten nicht auch value1 anstatt value stehen?
Ein Beispiel zum constructor chaining wäre auch sinnvoll, z.B.:
BaseClass()
DerivedClass( int value ) : base( value ) (nicht signierter Beitrag von 84.180.174.236 (Diskussion | Beiträge) 15:44, 9. Apr. 2009 (CEST)
thread_title:  Codebeispiele 

message: "In C++ beispielsweise ist es notwendig, konstante Elemente [...] zu definieren, noch bevor der Geltungsbreich des Konstruktors beginnt"
Dies ist nicht korrekt. Wurde ein Member als "const" deklariert, ist er in allen Methoden "const" - nicht aber im Konstruktor.
: Hier muss ich (Peu) leider widersprechen, vielleicht sehen das einige Compiler so, oder man kann das in Java beobachten, in C++ besteht
: tatsächlich die Notwendigkeit, const-Member so früh zu initialisieren, auch wenn es eher ärgerlich ist. So kann man das in der ISO-Norm
: nachlesen und bei Stroustrup, Die C++-Programmiersprache; hier geht der (")Schöpfer(") sogar so weit, zu erklären, wie man Exceptions
: fängt, die während der Abarbeitung der Initialisierungsliste auftreten. Für solche Spezialitäten gäbe es keine Notwendigkeit, wenn
: C++ nicht die Initialisierung noch vorm Betreten des Konstruktor-Blocks erfordern würde. Hält man den Java-Weg dagegen wirkt das alles
: doch wesentlich entspannter...
: für C++ siehe z.B. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndeepc/html/deep102199.asp
Peu 22:27, 22. Jan 2006 (CET)
replies: text:  Oha. Eigenartig, ich hätte gedacht, das mal anders gelesen zu haben. Aber du hast absolut Recht... ich werde es gleich mal wieder mit reinnehmen. --141.24.45.85 14:16, 23. Jan 2006 (CET)
thread_title:  C++: Konstruktor und konstante Objekte 

message: Es scheint, als wollte der ein oder andere sehr gern ins Detail gehen z.B. in der C++-Sicht auf die Dinge. Konstruktoren und Destroktoren sind allerdings gemeinsam stark an das Konzept der "Objekt-Lebenszeit" gekoppelt. Würde man bezüglich C++ so richtig loslegen, müssten
auf jeden Fall Kopier-Konstruktoren und Zuweisungsoperatoren zur Sprache kommen. 
Allerdings scheint mir dann doch eine Verteilung auf zwei Artikel gerechtfertigt, da Java nun mal keine Destruktoren hat und in C++ die
Spiegelbildlichkeit der beiden Methoden einer speziellen Darstellung bedarf. Insofern halte ich die Integration eines C++-Codebeispiels
nicht für gut, solange nicht mindestens eines in Java enthalten ist.
: Das Konzept der Objekt-Lebenszeit wird ja nicht außer Acht gelassen. Allerdings ist das meiner Ansicht nach völlig unzureichend wenn man weiß, dass ein Destruktor eine Funktion ist, die am Ende des Lebenszyklus aufgerufen wird und Aufräumungsarbeiten aufführt. Als ich damals C++ lernte, las ich genau diese Beschreibung und wusste nichts damit anzufangen. Der C++-Code soll nur ein Beispiel für die Benutzung von Konstruktoren und Destruktoren sein. Ich denke, da spricht nichts dagegen? Natürlich kann jemand noch ein Java-Beispiel hinzufügen. Einen Artikel für 'Kopierkonstruktor' habe ich heute Nacht noch geschrieben und die Zuweisungsoperatoren hatte ich vor längerer Zeit mal auf 'überladen' erklärt. Ich verstehe dein Argument für die Trennung von Konstruktoren und Destruktoren nicht ganz. Ich glaube du willst darauf hinaus, dass Java keine Destruktoren im eigentlichen Sinne hat und der Konstruktor dann nicht einfach "gespiegelt" werden kann? Hmm... ja. Sollte man vielleicht deshalb wirklich trennen... ich glaube aber, das ist so ausreichend. --141.24.45.85 14:26, 23. Jan 2006 (CET)
thread_title:  Artikelbezeichnung 

message: Der Artikel ist zu sehr wie für ein Lehrbuch geschrieben und verfehlt daher den enzyklopädischen Charakter. Außerdem ist er stellenweise unverständlich und insgesamt schlecht strukturiert. Ich bitte die Hauptautoren, den Artikel zu überarbeiten. --Knorxx 11:56, 29. Jan 2006 (CET)
thread_title:  Überarbeiten 

message: Das zum Destruktor alternative Konzept Finalisierung nimmt mehr Raum ein als der Destruktor selbst. Die Gurke besteht zu 97 Prozent aus Wasser. Ich komme nicht von der Idee weg, dass Konstruktoren und Destruktoren die Aufgabe haben, ein Objekt zunächst in den Zustand zu versetzen, der von "seinem Benutzer" erwartet wird (Vertrag mit der Typisierung: Klasse Interface). Insofern bestimmen sie nicht einfach die Lebenszeit eines Objekts (obwohl das schon so heißt), sondern die Einhaltung von Zusicherungen über Eigenschaften und Verhalten: Der erste reguläre Methodenaufruf an das Objekt kann nach Abschluss des Konstruktors die volle Einsatzbereitschaft des Objekts erwaten und gewähren, und nach dem Abschluss des Destruktors kann der Benutzer des Objekts davon ausgehen, das alles was das Objekt gebunden hatte an Ressourcen wieder an verfügbar ist. Die Ressourcenbilanz ist üblicherweise (na ja) plus minus null. Also hat ein Artikel über Konstruktoren und Destruktoren eher etwas mit C++ zu tun als mit Java. Gut das müsste man jetzt für normale Menschen übersetzen, worin ich wohl scheitere. --Peu 23:24, 6. Feb 2006 (CET)
replies: text: Siehe Invariante. Ein wichtiger Aspekt, der im Artikel noch fehlt. Mein Tipp: Sei mutig und versuch dich mal daran. :-) --Knorxx 13:08, 12. Feb 2006 (CET)
thread_title:  Finalisierung nimmt zu viel Raum ein 

message: Der Link führt auf Grund der Redirektion (scheinbar ein Bug im REDIRECT) zum Anfang des Artikels über Automatische Speicherbereinigung.
Mit dem 'Siehe auch' am Ende des Artikels ergeben sich so 3 Verweise auf denselben Artikel, der mit diesem nicht sooo viel zu tun hat. --Peu 23:31, 6. Feb 2006 (CET)
thread_title:  Link Finalisierung wird falsch redirigiert 

message: wie wäre es nicht mehr Zerstörung von Variablen zu schreiben, sondern freigeben von speicher?
:Tja, das wäre falsch. Denn der Unterschied zwischen Destruction („Zerstörung“) und bloßer Speicherfreigabe besteht ja eben darin, dass auch andere Ressourcen außer Speicher befreit und weitere Aufräumarbeiten durchgeführt werden können. --jpp ?! 12:39, 9. Mai 2006 (CEST)
thread_title:  dies und das 

message: Im Artikel steht: 
a) Um ein Objekt einer bestimmten Klasse herzustellen, wird ein Konstruktor ausgeführt; er stellt sozusagen das Rezept dar, nach dem aus dem vorliegenden Zutaten unter den gegebenen Bedingungen ein Objekt erstellt wird.
Meine Meinung dazu:
* Die Formulierung "herzustellen" ist unglücklich gewählt. Besser wäre "zu erstellen" oder "zu erzeugen".
* Ich finde, einen Konstruktor als Rezept zu bezeichnen, nach dem ein Objekt erstellt wird, trifft die Sache nicht. Damit wird dem Konstruktor viel zu viel Bedeutung beigemessen. Als "Rezept" könnte man vielleicht die dazu gehörende Klasse bezeichnen, ein Konstruktor dient aber lediglich der Initialisierung. 
b) In den meisten objektorientierten Programmiersprachen sind Klasse und Konstruktor namensgleich, worin sich die essentielle Bedeutung des Konstruktors für die Klasse wiederspiegelt.
* Zu sagen, in der Namensgleichheit spiegele sich die essenzielle Bedeutung wider, halte ich für etwas zu hoch gegriffen. Was ist denn dann mit den Programmiersprachen, bei denen der Konstruktor nicht den gleichen Namen wie die Klasse hat?
c) Im Gegensatz zu Konstruktoren ist pro Klasse nur ein Destuktor erlaubt.
* Bist du dir sicher, dass das für alle Programmiersprachen gilt?
d) Für Klassen, deren Objekte keine externen Ressourcen benötigen, wird üblicherweise auf die Festlegung eines Destuktors verzichtet.
* Das stimmt nicht. Destruktoren übernehmen auch andere Aufgaben als die Verwaltung der eigenen Ressourcen.
--Knorxx 11:53, 15. Jun 2006 (CEST)
thread_title:  Sonstiges 

message: * Default-Konstruktor: public Object()
* Copy-Konstruktor: public Object( Object object)
gibt es sonst noch welche?
hat so ein alternativer konstruktor zB eine spezielle bezeichnung, der einen anderen konstruktor mit vorgegebenen werten aufruft:
public Object( int value) : this( value, "bla")
-- Qopep 21:15, 4. Sep 2006 (CEST)
replies: text: Das obige Beispiel scheint für Java zu gelten. Soweit ich weiß, sind in C++ und Java diese beiden speziellen Konstruktoren bekannt, ansonsten kann eine wahre Flut von Konstruktoren definiert werden. In C++ kann das sehr lästig werden, da hier ein immer nur genau ein Konstruktor zur Erstellung eines Objekts zur Anwendung kommt, d.h. man kann die Implementierungen anderer Konstruktoren für ein gegebenes Objekt nicht aufrufen (wohingegen das in Java - siehe oben - nicht nur erlaubt, sondern absolut üblich ist). Gruß --Peu 18:49, 25. Jan. 2007 (CET)

text: Im Buch Accelerated C# wird das o.g. Beispiel "constructor forwarding" genannt -- Qopep 02:23, 27. Dez. 2008 (CET)
thread_title: Konstruktortypen

message: In Java ist ein parameterloser Konstruktor, der explizit definiert wird, *kein* "Default-Konstruktor". Falls das z.B. in C++ anders ist, bitte ich die Formulierung spezifischer zu machen. Ich möchte der fehlerträchtigen Unsitte entgegenwirken, dass manche Leute ohne Sinn und Zweck erstmal einen parameterlosen Konstruktor in jede Klasse schreiben, weil sie das für eine Art Default halten. (nicht signierter Beitrag von Towopedia (Diskussion | Beiträge) 21:58, 3. Jun. 2011 (CEST)
thread_title: Falsches Verständnis von Default-Konstruktor

message: Habe neulich nach der Bedeutung des Begriffs "ctor" gesucht und hier nicht gefunden. Das ist die Abkürzung für engl. "constructor". Daneben gibt es "dtor" für "destructor".
Grüße OnkelSchuppig 20:19, 22. Nov. 2008 (CET)
replies: text: Wo wird diese Abkürzung verwendet? Wikipedia:Einzelnachweis? --j ?! 14:09, 27. Nov. 2008 (CET)
replies: text: In Compiler Fehlermeldungen sowie in englischsprachigen Foren OnkelSchuppig 20:10, 30. Nov. 2008 (CET)
replies: text: Welcher Compiler gibt diese Fehlermeldungen aus? Sind sie evtl. irgendwo online? --j ?! 23:18, 30. Nov. 2008 (CET)
replies: text:  Doch die Abkürzungen ctor und dtor sind eigentlich schon geläufig und tauchen auch in Abkürzungsverzeichnissen auf. In .NET ist die interne Bezeichnung der Konstructor-Routine im IL-Code ".ctor" aber ich kenne die Abkürzungen auch von früher aus dem C++ Umfeld. (nicht signierter Beitrag von 84.180.174.236 (Diskussion | Beiträge) 17:51, 9. Apr. 2009 (CEST)
thread_title: Abkürzung ctor und dtor

message: Da der alte Artikel mir der Aufbau des alten Artikels nicht gefiel, habe ich den ganzen Artikel mal umgeschrieben. Dabei habe ich versucht, den vorherigen Inhalt so gut wie möglich drin zu lassen und einige Sätze habe ich gleich 1:1 übernommen. Hier noch einige Fragen, die ich noch gerne geklärt hätte:
* Jeder Typ kann maximal ein Destruktor definieren. Ist das bei allen Sprachen so?
:* Gibt es Sprachen, die Destruktoren mit argumenten unterstuetzen? --> Möglichkeit für verschiedene Destruktoren
* Rein vom Konzept würde ich sagen, dass Konstruktoren/Destruktoren nicht fehlschlagen können/dürfen. hab dafür keine bestimmte Quelle ausser "Hab ich mal irgendwo gehört", kann das jemand auf Korrektheit überprüfen? Falls das so ist fände ich die Info noch nennenswert.
: Soweit mir bekannt können und sollen Konstruktoren fehlschlagen dürfen, wenn mit den gegebenen Argumenten das erzeugte Objekt in keinen konsistenten Zustand gebracht werden kann. Wie sich das bei Destruktoren verhält, weiß ich nicht, halte ich aber für zweifelhaft, denn bei vielen Objekten wird dieser erst bei Programmende aufgerufen, wenn es für eine angemessene Fehlerbehandlung zu spät ist. In dem Fall wäre ein stabiler Shutdown nicht mehr möglich. --77.21.93.83 13:34, 18. Jan. 2011 (CET)
thread_title:  Überarbeitung und Neustrukturierung