Diskussion:Konstruktoren und Destruktoren

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) jpp ?! 12:39, 9. Mai 2006 (CEST))

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)