Destruktor von DynamicArray<type>
-
Wie sieht denn der Desruktor bei DynamicArrays aus?
class CKnoten { public: CKnoten *Parent; DynamicArray<CKnoten*> Children; CKnoten() { Children.Length = 0; }; ~CKnoten() { ??????? }; Insert(CKnoten *Knoten) { Children.Length += 1; Children[Children.High] = Knoten; }; };
-
RTFM
da steht:Don’t call the dynamic array destructor. To free a dynamically allocated DynamicArray, assign it a Length of zero.
~CKnoten() { Children.Length = 0; };
-
... und (das hätt ich fast vergessen) Du solltest natürlich die einzelnen Elemente vorher löschen:
for(int loop=0; loop<Children->Length; ++loop) delete Children[loop];
-
Christian Sonder schrieb:
Don’t call the dynamic array destructor. To free a dynamically allocated DynamicArray, assign it a Length of zero.
Das DynamicArray wurde hier aber nicht dynamisch, sondern auf dem Stack alloziert. Es sollte daher reichen, die einzelnen Einträge mittels delete zu löschen. Da DynamicArray ein Stackobjekt ist, wird es automatisch destruiert und der von ihm belegte Speicherplatz freigegeben.
Ein paar Anmerkungen zum Code:
- warum DynamicArray, wenn es std::vector gibt und du damit compilerunabhängig bist?
- Wenn du Parent und Children als public deklarierst, sagst du jedem Benutzer der Klasse "mach mit diesem Objekten, was du willst". (Zumindest wird sich unter den Benutzern, du selbst nicht ausgeschlossen, bald jemand finden, der sich dann so angesprochen fühlt. Oft reicht es sogar, sich zu vertippen, um die Klasse zu fehlerhaftem Verhalten zu bringen.)
- Generell wäre es sinnvoll, nicht Zeiger, sondern Referenzen auf CKnoten zu übernehmen. Einer der vielen Gründe dafür ist, daß für Zeiger auch NULL übergeben werden kann und du als Entwickler diesen Fall berücksichtigen solltest.
- wie und mit welcher Lektüre hast du C++ gelernt? Zufällig mit Visual C++ und MFC?
-
@audacia:
stimmt, da war ich wohl zu blöd zum lesen
-
Ich danke erstmal für die Antworten!
C++ gelernt habe ich mit Borland C++ Builder.
std::vector habe ich noch nie gehört ... was ist das?Ich mache erstmal wenn ich was programmiere alles public. Wenn ich dann fertig bin rationalisiere ich alles weg was nicht öffendlich sein muss.
"nicht Zeiger, sondern Referenzen" - wie würde das konkret im Beispiel aussehen?
Grüße
-
t.jay03 schrieb:
std::vector habe ich noch nie gehört ... was ist das?
Der Container vector gehört zum C++Standard.
Lies mal diesen Beitrag aus dem Magazin.
http://www.c-plusplus.net/forum/viewtopic-var-t-is-143816.html
-
t.jay03 schrieb:
Ich mache erstmal wenn ich was programmiere alles public. Wenn ich dann fertig bin rationalisiere ich alles weg was nicht öffendlich sein muss.
Wenn du meinst. Generell ist es empfehlenswert, zunächst die Schnittstelle zu definieren und dann Implementationsdetails zu klären, das sorgt für eine größere Konsistenz und mehr Übersicht bei der Planung, da du dir zunächst überlegen mußt, was deine Klasse alles können und wie das zu benutzen sein soll.
t.jay03 schrieb:
"nicht Zeiger, sondern Referenzen" - wie würde das konkret im Beispiel aussehen?
Z.B. so:
// .hpp-Datei #ifndef _MYNODE_HPP #define _MYNODE_HPP #include <vector> class MyNode { public: MyNode (void); MyNode (const MyNode& parent); ~MyNode (void); void insertNode (const MyNode& node); ... private: MyNode* parentNode; std::vector <MyNode*> childNodes; ... }; #endif // _MYNODE_HPP // .cpp-Datei void MyNode::insertNode (const MyNode& node) { childNodes.push_back (&node); } ...
-
audacia schrieb:
Wenn du meinst. Generell ist es empfehlenswert, zunächst die Schnittstelle zu definieren und dann Implementationsdetails zu klären, das sorgt für eine größere Konsistenz und mehr Übersicht bei der Planung, da du dir zunächst überlegen mußt, was deine Klasse alles können und wie das zu benutzen sein soll.
sehe ich ein! Versuche mich daran zu halten!
& Danke fürs Beispiel
