🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: de.comp.lang.c++
Article #1219

Re: Ueberladen ... Problem ... Dringend

#1219
From: Karsten Baensch
Date: Wed, 10 Jan 1996 07:34
85 lines
4705 bytes
kuehl@uzwil.informatik.uni-konstanz.de (Dietmar Kuehl) writes:

>Hi,
>Karsten Baensch (kba@hrz.tu-chemnitz.de) wrote:
>: Selbst der Destruktor ist nicht ganz korrekt. Es muss heissen:
>: vektor::~vektor()
>: {
>:   delete[] pointer;
>: }
>: (Fuer den Fall des int-Arrays haette der 'normale' delete-Operator
>: vielleicht auch funktioniert.

Na mal langsam! Mein Statement war:
"Selbst der Destruktor ist nicht ganz korrekt. Es muss heissen:
 vektor::~vektor()
 {
   delete[] pointer;
 }
 (Fuer den Fall des int-Arrays haette der 'normale' delete-Operator
 vielleicht auch funktioniert. Aber stelle Dir ein mit new[] angelegtes
 Array selbstdefinierten Typs vor! Dann wuerde mit delete ohne[] nur das
 erste Element beseitigt werden!)"

>* N * E * I * N * !!!! Auf Array Objects MUSS IMMER delete[] angewendet
>werden! IMMER! KEINE AUSNAHME!  Das es uU. mit einem bestimmtem
>Compiler funktioniert heisst nicht, dass es "vielleicht auch
>funktioniert"! Es ist FALSCH!

Sicher hast Du Recht, mit dem was Du da meinst. (Ich nehme an, Du meinst
mit 'Array Objects' auch Arrays von Objekten; ein echtes 'Array Objekt', also
ein Container, ist hier ebenfalls denkbar, auf den niemand ein 'delete[]'
anwenden wuerde.:-)) 
Aber was regst Du Dich so auf? Meine Behauptung: "Fuer den Fall des int-Arrays
haette der 'normale' delete-Operator vielleicht auch funktioniert." sagt
nichts weiter aus, als das es eben 'vielleicht auch funktioniert' 'haette'.
Und das ist voellig korrekt. (Die Behauptung war weder eine Wertung des
Programmierstils; ausserdem habe ich die korrekte Implementation des Destruktors
ja vorweggenommen. Und das Woertchen 'vielleicht' regt jeden Programmierer an,
darueber nachzudenken, wie und warum er es auf das 'vielleicht' eben nicht
ankommen lassen sollte. Also zieh Dich nicht an solchen Wortspielereien so hoch!)

>Wenn es mit einem Compiler funktioniert,
>dann liegt das einfach daran, dass das "undefined behavior" bei diesem
>speziellen Compiler gerade das macht, was uU. gedacht war

Also mit anderen Worten: 'Es haette vielleicht auch funktioniert!'
(Und bei GNU und Borland tuts das meines Wissens nach auch.)
Meister Stroustrup selbst hat es in
Ellis, M.A., Stroustrup, B.: The Annotated C++ Referenz Manual, Addison-Wesley, 1990
S. 65 so formuliert:
"Typically, the distinction between deleting an object and an array of objects is sig-
 nificant only when deleting objects of a class with a destructor. Then, the number
 of objects deleted determines the number of times the destructor must be called. Con-
 sequently, one could consider requiring the delete[] notation only for pointers to
 such classes. ..." (Danach beschreibt er/sie, warum man es so eben nicht tun sollte.)

>(was eigentlich? Werden die Destruktoren aufgerufen? Welche Funktion wird
>zum freigeben verwendet, 'operator delete()' oder 'operator
>delete[]()'?).

Natuerlich werden fuer Objekte von Klassen mit Destruktoren diese aufgerufen, und 
zwar sooft, wie sich Objekte im Array befinden. Zur Frage mit den Operatorfunktionen
dieses (obige Literatur, S. 64):
"... For objects of a nonclass type (including
 arrays of class objects), the global ::operator delete() is used. For an
 object of a class T, T::operator delete() is used if it exists (using the usual
 lookup rules for finding members of a class and its base classes; ss10.1.1); other-
 wise the global ::operator delete() is used. ..."
Also ganz easy, eigentlich.

>Ein anderer Compiler kann beliebig unsinnigen Code
>erzeugen, wenn er auf etwas trifft, was in "undefined behavior"
>resultiert: Angefangen bei einem Absturz des Programms (ggf. des
>gesamten Systems) bis hin zu richtig boesen Schaeden (zB. das bekannte:
>"alle Files loeschen").

Nanana. Hier spricht wohl der Experte 8-)? Ihr solltet eben nur Betriebssysteme anstatt
DOSen verwenden, gelle?

Karsten
--
(  Email: Karsten.Baensch@hrz.tu-chemnitz.de                                ( 
 ) WWW:   http://www.tu-chemnitz.de/~kba/baensch.html                        )
(  Phone: (+49-) 0371/531-1252                                              ( 
 ) Mail:  Technical University, Computing Services, 09107 Chemnitz, Germany  )
Technical Details
Message-ID: <4d0216$6op@pyrrhus-f.hrz.tu-chemnitz.de>
Path: arc1-ca.pugleaf.net!news.tu-chemnitz.de!news
References: <4cqs22$2ou@rztsun.tu-harburg.de> <4ctel8$fv8@pyrrhus-f.hrz.tu-chemnitz.de> <30f2a556.0@news.uni-konstanz.de>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!news.tu-chemnitz.de!news
From: kba@hrz.tu-chemnitz.de (Karsten Baensch)
Newsgroups: de.comp.lang.c++
Subject: Re: Ueberladen ... Problem ... Dringend
Date: 10 Jan 96 07:34:55 GMT
Organization: University of Technology Chemnitz, FRG
Message-ID: <4d0216$6op@pyrrhus-f.hrz.tu-chemnitz.de>
References: <4cqs22$2ou@rztsun.tu-harburg.de> <4ctel8$fv8@pyrrhus-f.hrz.tu-chemnitz.de> <30f2a556.0@news.uni-konstanz.de>
NNTP-Posting-Host: shark.hrz.tu-chemnitz.de