Diskussion:Konstruktoren und Destruktoren

Codebeispiele

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))

C++: Konstruktor und konstante Objekte

"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)

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)

Artikelbezeichnung

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)

Überarbeiten

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)

Finalisierung nimmt zu viel Raum ein

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)

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)

Link Finalisierung wird falsch redirigiert

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)

dies und das

wie wäre es nicht mehr Zerstörung von Variablen zu schreiben, sondern freigeben von speicher? (nicht signierter Beitrag von 84.189.169.225 (Diskussion) )

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)

Objektorientierte Programmierung

Kommen Konstruktoren nur in der objektorientierten Programmierung vor?

Im einleitenden Satz steht jetzt In der objektorientierten Programmierung wird die Herstellung und der Abbau von Objekten durch Konstruktoren und Destruktoren geregelt. - Konstruktoren und Destruktoren kommen aber nicht nur in der objektorienterten Programmierung vor, deswegen halten ich den Satz für verfehlt.
Zudem wurde aus der gesamte Artikel so umgestrickt, dass er sich nur noch auf die objektorientierte Programmierung bezieht. Ich fürchte, so können wir das nicht lassen. --Knorxx 22:40, 27. Mai 2006 (CEST)

Ich nehme an, du spielst auf java an. Natürlich stimmt das, aber mir passt dieser Verbundartikel ja sowieso nicht! Wenn ich ihn auseinander nähme (warum hat ihn überhaupt jemand zusammengelegt???), käme ich allein nicht durch. Es gibt Sprachen, die objektorientiert sind und ohne Destruktor daherkommen (java). Es gibt sogar Sprachen, die ohne Konstruktor daherkommen, aber alle Ansätze, die ich kenne (ich kenne nicht viele und Smalltalk z.B. überhaupt nicht), sind lausig was Zusicherungen betrifft. C++ ist sehr streng mit Konstruktor und Destruktor, und natürlich auch ein bisschen blöd... Was nun? ALSO: Ich meine, ein Artikel über "Konstruktoren und Destruktoren" ist unnütz oder unverständlich (und wahrscheinlich beides). (Ach so, deine Kritik lautete "Konstruktoren und Destruktoren kommen nicht nur in der Objektorientierten Programmierung vor", aber worauf du damit hinauswillst, kann ich nicht erkennen!) --Peu 22:24, 28. Mai 2006 (CEST)

Konstruktoren und Destruktoren außerhalb der Objektorientierten Programmierung? Das ist auch mir vollkommen neu. Könntest du ein Beispiel dafür bringen? --jpp ?! 23:20, 28. Mai 2006 (CEST)

Zum Beispiel C++: Niemand zwingt dich, Konstruktoren oder Destruktoren für die objektorientierte Programmierung einzusetzen.
Die Zusicherungen, die Peu erwähnt hat, finde ich einen interessanten Aspekt, der sich meiner Meinung nach gut im Artikel machen würde. Siehe auch Invariante. --Knorxx 20:21, 29. Mai 2006 (CEST)

Das Beispiel C++ ist ja Quatsch. Die Konstruktoren und Destruktoren werden auch in C++ nur in Zusammenhang mit Klassen verwendet. Alles andere geht an den Grundideen vorbei und hat eher den Charakter „schmutziger Tricks“. --jpp ?! 22:55, 29. Mai 2006 (CEST)

Wer sagt denn, dass man Klassen für objektorientierte Programmierung verwenden muss? --Knorxx 18:46, 30. Mai 2006 (CEST)

Worauf spielst du hier an (ich meine welche Sprache)? Im Ernst, Klassen sind wirklich (mit Verlaub) sehr praktisch, wenn man oo programmieren will; natürlich geht es auch anders (z.B. in der Sprache Self, wenn ich das richtig verstanden habe), aber der Mainstream ist (noch?) OOP mit Klassen. --Peu 21:42, 30. Mai 2006 (CEST)

Wohl ein Missverständnis. Ich sage, man muss Klassen nicht unbedingt für objektorientierte Programmierung verwenden. Also auch nicht Konstruktoren und Destruktoren. Objektorientierung ist nur ein Ausschnitt aus der Menge der Anwendungsmöglichkeiten. --Knorxx 17:07, 31. Mai 2006 (CEST)

In C++ muss man Klassen verwenden, wenn man objektorientiert programmieren will. In Java läuft ohne Klassen gar nichts, da sind wir uns auch einig. Du meinst aber, ich hoffe ich versteh' es jetzt richtig, man könne mit Klassen auch andere Dinge anstellen als oo Programme zu entwickeln, da stimme ich dir zu, aber das ist wohl eher als ein Abfallprodukt zu verstehen. (Man kann die Bedeutung von Konstruktoren und Destruktoren übrigens sehr schön bei Stroustrup nachlesen, im Kapitel 10.4 Objekte von ISBN 3827317568) Im Artikel sollte wohl dargestellt werden, dass es Programmiersprachen gibt, die Objekte als Exemplare von Klassen begreifen; in der Definition der Klassen wird dem Entwickler die Möglichkeit gegeben, Festlegungen darüber zu treffen, wie die entsprechenden Exemplare auf- und abgebaut zu werden haban. --Peu 20:56, 31. Mai 2006 (CEST)

man könne mit Klassen auch andere Dinge anstellen als oo Programme zu entwickeln, da stimme ich dir zu, aber das ist wohl eher als ein Abfallprodukt zu verstehen. - Nein, da liegst du falsch. Beispiel: struct a { int i; }; struct b { int i; b() : i(0){} }; Handelt es sich nun bei struct b um objektorientierte Programmierung, nur weil ein Konstruktor verwendet wird? Wohl kaum. Also: Konstruktoren und Destruktoren sind kein Konzept der objektorientierten Programmierung, auch wenn sie dort angewendet werden. --Knorxx 19:44, 2. Jun 2006 (CEST) PS: Was genau schreibt Stroustrup an der von dir genannten Stelle? Habe im Moment kein Buch zur Hand und wäre dir dankbar, wenn du den Inhalt kurz umreißen würdest.

Nein, da liegst du falsch. Beispiel: struct a { int i; }; struct b { int i; b() : i(0){} } - Ich bleibe dabei. "Abfallprodukt". dieses Beispiel ist natürlich nicht oo, aber der Konstruktor ist ja auch völlig überflüssig. Vielleicht könnte man es so sagen: Wenn man Konstuktoren wirklich braucht, dann handelt es sich um OOP, denn dann hat man wohl Bedarf am atomaren Aufbau einer konsistenten Umgebung, in der Elementfunktionen ihren Dienst leisten können. --Peu 19:24, 5. Jun 2006 (CEST) ...wenn du wirklich Interesse an dem Stroustrup-Text hast, würde ich ihn dir persönlich zitatweise zumailen, ich denke sinngemäß wäre hier verfehlt. (bei einer Einrückungstiefe von 9)

So, erst mal die Sache mit der Einrücktiefe richten :-) ... Wenn es ein Abfallprodukt wäre, wäre das unerheblich. Ist es aber nicht, denn Konstruktoren werden zum Beispiel auch für abstrakte Datentypen eingesetzt, dabei handelt es sich also um ein breites Anwendungsgebiet. Und auch int-Datentypen haben in C++ Konstruktoren. Wusstest du das nicht? Du kannst übrigens die Hauptmerkmale der objektorientierten Programmierung hier nachlesen, und da sind Konstruktoren selbstverständlich nicht enthalten. --Knorxx 19:55, 6. Jun 2006 (CEST)

1. C++ ist als C mit Klassen sozusagen geboren worden. Hätte man auf Klassen verzichten können, dann wäre C++ wohl nicht entstanden (und natürlich beabsichtigte man mit Klassen nichts anderes, als objektorientiert arbeiten zu können)
2. OOP nach dem von dir zitieren Artikel spiegelt nicht ganz die C++-Sicht wider. Aber C++ räumt ja gerade Konstruktoren und Destruktoren eine besondere Bedeutung ein. (Für mir ist im übrigen nicht klar, weshalb im genannten OO-Artikel nicht auf Besonderheiten bei der Konstuktion eingegangen wird, bei einer statisch und streng typisierenden Programmiersprache würde an die Konstruktion immer die Anforderung einer Unteilbarkeit gestellt werden müssen und andererseits die Einhaltung der deklarierten Eigenschaften/Dienstbarkeiten)
3. Konstruktoren stellen das Mittel dar, Invarianten (als entscheidendes Kriterium sauberer OOP) mit C in Einklang zu bringen: dort, wo bei C eine Deklaration (z.B. einer struct) stünde, muss jetzt ein Objekt einer Klasse deklariert werden können, was einerseits (C-Sicht) eine Variable ins Spiel bringt, andererseits eine sichere Initialisierung erzwingt (C++-Sicht).
4. Die in C bestehende Möglichkeit, automatische Variablen (auch strukturierte) zu deklarieren, erzwang in C++ schließlich die Entwicklung von Destruktoren, deren Aufruf durch den Compiler garantiert wird, egal auf welchem Wege der Gültigkeitsbereich einer (nichttrivialen) Variablen verlassen wird.
5. Konstuktoren für eingebaute Typen (z.B. int) sind notwendig für die Entwicklung von Templates, dem ist übrigens auch die Möglichkeit, in einer void-Funktion mit dem return-Statement das "Ergebnis einer void-Funktionen" zu returnieren.
6. schließlich: was ADT und Konstruktoren miteinander zu tun haben, würde ich gern einmal erklärt bekommen...--Peu 21:42, 6. Jun 2006 (CEST)

Peu, zuvor eine Sache: Ich weiß bei manchen deiner Beiträge nicht, worauf du damit eigentlich hinaus willst. Das, worum es im Moment geht, ist doch die Frage, ob Konstruktoren bzw. Destruktoren auch außerhalb der objektorientierten Programmierung eingesetzt werden. Wenn du aber z.B. schreibst "in einer void-Funktion mit dem return-Statement das "Ergebnis einer void-Funktionen" zu returnieren.", dann stehe ich vor einem Rätsel. Was willst du damit denn sagen?

was ADT und Konstruktoren miteinander zu tun haben, würde ich gern einmal erklärt bekommen: Siehe dazu bei Stroustrup in Kapitel 2.4. (oder 2.5., bin mir jetzt nicht sicher) Darin geht es um abstrakte Datentypen in C++. Lies das erst mal durch. Danach diskutieren wir weiter.

--Knorxx 19:27, 8. Jun 2006 (CEST)

Der "Datenabstraktion" ist das Kapitel 2.5 (Stroustrup, Die C++-Programmiersprache) gewidmet, in 2.5.4 geht es um "Abstrakte Typen". Und ich schließe aus der Lektüre, das Konstruktoren und Destruktoren damit nichts zu tun haben. Die Bedeutung des Wortes Konstruktor im Artikel über ADT ist wohl eine völlig andere. (Im Übrigen: gerade ein Konstruktor ist immer konkret.) Was ich mit der void-Kiste meinte, nun das ist die Erläuterung zu Spracheigenschaften - wie Pseudo-Konstruktoren im Falle von int -, die der Templatefähigkeit von C++ geschuldet sind... aber ehe wir uns mit diesen Dingen noch bis in alle Ewigkeit streiten, mal was Konstruktives: Was hältst du (und vor allem die anderen) denn von der Relativierung in der Einleitung des Artikels? --Peu 21:31, 8. Jun 2006 (CEST) auch wenns vielleicht etwas bissig klingt: ich verstehe nicht recht, wie eine Enzyklopädie substantiell angereichert werden kann, wenn die Recherche oftmals in Inhalten ihrer eigenen Artikel gefangen bleibt.

Was ich vom einleitenden Satz halte, habe ich ja schon gesagt. Zur Recherche: Die ist sehr wichtig, damit die Inhalte verlässlich sind. Wir müssen nicht möglichst viele Kilobytes auf dem Server ablegen. Es kommt vielmehr darauf an, dass das, was wir schreiben, das gegebene Thema so genau wie möglich wiedergibt.
Die int-Konstruktoren sind keine Pseudo-Konstruktoren. Wie kommst du darauf? Und wieso glaubst du, dass bei ADTs ein Konstruktor eine andere Bedeutung hat? --Knorxx 18:46, 9. Jun 2006 (CEST)

Meine Antworten:

1. Den einleitenden Satz hatte ich geändert und glaubte, ihn damit sachlich berichtigt zu haben.
2. Pseudokonstruktor in der Schreibweise pseudo-constructor findet sich z.B. in http://kungens.kemi.fi/eckel/TICPP-2nd-ed-Vol-two.zip (Bruce Eckel, Thinking in C++ Vol.2) allerdings beschreibt Strustrup sie als "function-style cast", der für eingebaute Typen äquivalent ist zu "static_cast<T>(a)". siehe ISBN 3-8273-1756-8, 6.2.8 Konstruktoren (Seite 141 oben), weiter schreibt Stroustrup, dass die (von ihm so genannte) Konstruktorschreibweise für eingebaute Typen besonders wichtig beim Schreiben von Templates sei (selbe Seite unten); das meinte ich mit meiner void-Asuschweifung.
3. ADT abstrakte Datentypen werden ja gerade nicht direkt instanziiert; ich kann deshalb nur annehmen, dass das Wort Konstruktor in diesm Artikel falsch hinterlegt wurde.

Meine Frage:

Wenn man z.B. einen Artikel "Konstruktor" in der Wikipedia akzeptiert, ist dann nicht klar, dass er in erster Linie an Software-ker gerichtet ist, wobei sicherlich sehr begrüßt wird, wenn normale Menschen verstehen worum es geht (dass es sie also

• entweder sowieso nicht interessiert oder
• sie durch die engestreuten Links Hintergründe erkennen ihr Wissen bereichern können)

Softwareentwicklung ist mein täglich Brot, und ich finde es erstaunlich, wie du, Knorxx, mich fachlich in C++ auf Trab bringen möchtest, du magst sicherlich recherchieren, aber ich sehe doch einen Mangel an Sachkenntnis.

--Peu 12:47, 10. Jun 2006 (CEST)

Hallo Peu,

• ich hatte nicht gesehen, dass du etwas am Artikel geändert hattest. Den Satz, den du hinzugefügt hast, finde ich gut. Der wichtige Punkt, dass nämlich Konstruktoren nicht nur im Zusammenhang mit der objektorientierten Programmierung verwendet werden, wurde aber immer noch nicht umgesetzt.
• Stroustrup bezeichnet nicht nur die Konstruktoren von eingebauten Typen als Funktions-Cast, sondern auch die von benutzerdefinierten Typen. Dass es für bestimmte Fälle synonyme Namen gibt, ändert nichts an der Tatsache, dass es sich um Konstruktoren handelt. In dem von dir weiter oben angegebenen Abschnitt 10.4 schreibt Stroustrup: Fundamentale Typen haben ebenfalls Default-Konstruktoren (letzter Satz im Unterabschnitt 10.4.2). Ich hoffe, damit ist der Fall jetzt geklärt, und wir können zu anderen Themen übergehen.
• Was du mit abstrakte Datentypen werden ja gerade nicht direkt instanziiert ist mir nicht klar. Darauf musst du aber auch nicht weiter eingehen, denn dass Konstruktoren nicht nur in der objektorientierte Programmierung vorkommen, habe ich ja bereits nachgewiesen (u.a. durch das Stroustrup-Zitat: Fundamentale Typen haben ebenfalls Default-Konstruktoren).
• Auch Artikel zu Software-Themen sind in der Wikipedia nicht in erster Linie an "Software-ker" gerichtet. Die Laienverständlichkeit sollte immer angestrebt werden. Zumindest die ersten Sätze sollten so geschrieben sein, dass ein Laie das Thema grob einordnen kann.
• Autoritätsargumente (Berufserfahrung) bringen uns meistens nicht weiter. Auch Experten können sich irren. Deshalb besteht in der Wikipedia die Konvention, dass Behauptungen auf Nachfrage nachgewiesen werden müssen.
• Die Unterscheidung zwischen Initialisierung von Werten und Ressourcen (hattest du mir auf meine Diskussionsseite geschrieben) finde ich übrigens auch gut. Sollten wir in irgendeiner Form im Artikel berücksichtigen. Noch wichtiger finde ich den Punkt "Invarianten". Das gehört auf jeden Fall in den Artikel.

--Knorxx 16:43, 10. Jun 2006 (CEST)

Sonstiges

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)

Der Artikel kommt nicht vom Fleck!

(hi Knorxx)
Ich bin erstaunt, wie diese Seite sich um Java, Python und das Alternative Konzept der Finalisierung dreht, und dreht, und dreht...
...übrigens werden Konstruktoren nicht bei der Initialisierung aufgerufen, oder doch? Ja, vielleicht sollte immer mindestens ein Konstruktor zugegen sein, wenn ein Objekt erstellt wird.

--Peu 22:15, 24. Jun 2006 (CEST) (könnten wir nicht mal aufhören mit dem Schnickschnack?)

• das alternative Konzept der Finalisierung: Was findest du daran nicht gut?
• übrigens werden Konstruktoren nicht bei der Initialisierung aufgerufen: Steht das irgendwo und soll deiner Meinung nach nicht dort stehen?
• vielleicht sollte immer mindestens ein Konstruktor zugegen sein, wenn ein Objekt erstellt wird: Was willst du damit sagen? Bitte drück dich etwas klarer aus.

--Knorxx 00:08, 25. Jun 2006 (CEST)

ok, ich war etwas spitz: die Formulierung die bei der Erzeugung und Zerstörung von Variablen aufgerufen werden hatte mir nicht gepasst. Sie tun genau das, was ihnen den Namen gibt: Konstruieren (Erzeugen) und Destruieren (Zerstören). Und zurück auf mein hohes Ross: was, meinst du, sei daran nicht essentiell??

• du bringst (nehme ich an) hier unbehauene Versatzstücken alter Versionen ein, warum sonst gehen die Links (mal wieder) auf Redirekts?
• da der Artikel (hatten wir auch schon!) nun mal so blöd heißt, sollte man nicht 25% mit alternativen Konzepten verbraten

--Peu 00:19, 25. Jun 2006 (CEST)

die Formulierung die bei der Erzeugung und Zerstörung von Variablen aufgerufen werden hatte mir nicht gepasst. Sie tun genau das, was ihnen den Namen gibt: Konstruieren (Erzeugen) und Destruieren (Zerstören).: Das ist nicht ganz richtig. Wie wir ja bereits ausgeführt haben, werden Kon-/De-struktoren auch für andere Zwecke verwendet. Ferner spezifizieren sie nur den vom Programmierer vorgegebenen Anteil der Kon-/De-struktion. Insofern passt die Formulierung "bei der Erzeugung ...".

was, meinst du, sei daran nicht essentiell?: Ich habe nicht gesagt, Kon-/De-struktoren seien nicht essenziell, sondern mich gegen die Formulierung gewandt, die essenzielle Bedeutung spiegele sich in der Namensgleichheit wider.

du bringst (nehme ich an) hier unbehauene Versatzstücken alter Versionen ein, warum sonst gehen die Links (mal wieder) auf Redirekts?: a) Es steht die frei, die "Redirekts" in Links auf echte Artikel zu verwandeln.
b) Bei den vielen grundsätzlichen Mängeln, die du mit deiner Änderung eingebracht hast, wäre es angebracht gewesen, den Artikel sofort zu revertieren. Nur mit Rüchsicht auf deine geringe Erfahrung habe ich das nicht getan, sondern hier eine Diskussion gesucht, um gemeinsam eine brauchbare Variante zu erarbeiten. Nachdem du dich aber an der Diskussion nicht mehr beteiligt hast, habe ich die Konsequenzen gezogen.

da der Artikel [...] nun mal so blöd heißt: Bitte bleib sachlich, sonst lehne ich eine weitere Zusammenarbeit mit dir ab.

--Knorxx 14:10, 25. Jun 2006 (CEST)

Ich geb auf, du hast gewonnen! (der Artikel hat verloren) --Peu 20:12, 25. Jun 2006 (CEST)

Ich finde den Artikel etwas zu speziell, so kann man zB in Haskell über Konstruktoren neue Datentypen definieren.

Konstruktortypen

• 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)

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)

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

Falsches Verständnis von Default-Konstruktor

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))

Abkürzung ctor und dtor

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)

Wo wird diese Abkürzung verwendet? Wikipedia:Einzelnachweis? --j ?! 14:09, 27. Nov. 2008 (CET)

In Compiler Fehlermeldungen sowie in englischsprachigen Foren OnkelSchuppig 20:10, 30. Nov. 2008 (CET)

Welcher Compiler gibt diese Fehlermeldungen aus? Sind sie evtl. irgendwo online? --j ?! 23:18, 30. Nov. 2008 (CET)

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))

Überarbeitung und Neustrukturierung

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)

• Gibt es Sprachen, in der Konstruktoren gebraucht werden um den Speicherplatz für das Objekt selbst zu reservieren? Also das wass bei C++ der Compiler übernimmt, wenn ich "new" sage

Gruss --Bernedom 13:44, 30. Nov. 2009 (CET)

Hab keine Ahnung von dem Thema... Für Einsteiger wars jetzt nicht so total verständlich! Vielleicht ein Link zu einem Einstiegs-Artikel. --arne (nicht signierter Beitrag von 217.231.84.29 (Diskussion) 08:49, 16. Apr. 2012 (CEST))