Verbesserungsvorschläge für mein Dynamische Pointer Array (Template)
-
Meine Aufgabe ist es ein Dynamisches Pointer Array zu schreiben, habe bisher die Funktion "add" und "getAt(int)" implementiert. Würde mich freuen wenn Verbesserungsvorschläge etc. kommen würden!
Hier der Code:
template <class T> class CDynPtrArray{ T **m_pArray; //Template Pointer Array int iSize; //Aktuelle Array Größe public: //Konstruktor CDynPtrArray(int iSize){ this->iSize=iSize; m_pArray= new T*[iSize]; } //Standart Konstruktor CDynPtrArray(){ this->iSize=0; m_pArray= new T*[0]; } //Destruktor ~CDynPtrArray(){ delete[] m_pArray; } //Size inline int GetSize(){ return iSize;} //Pointer adden void add(T* Ptr){ //Array um ein Elment vergrössern resize(iSize+1); //Pointer als letzes Element m_pArray[iSize]= Ptr; //Größe erweitern iSize++; } // Pointer zurückgeben T* getAt(int iPos){ if(iPos<0 || iPos>iSize) return NULL; return m_pArray[iPos]; } //BOOL delAt(int iPos){ // // if(iPos<0 || iPos>iSize) // return false; // //} private: void resize(int iNewSize){ T **ppNewArray= new T*[iNewSize]; //Referenzen kopieren for( int i=0; i< iSize; i++) ppNewArray[i]= m_pArray[i]; //Altes Array löschen und mit neuem Array referenzieren delete[] m_pArray; m_pArray= ppNewArray; } };
-
Meine Kritik: man sollte sich an den Schnittstellen der Standardlibrary halten. getAt und add sind für einen C++ler völlig unbekannt und inkompatibel. Besser wäre at() und ein Index-Operator (der auch eine Bereichsprüfung machen kann) und push_back(). Weiterhin ist ein begin() und end() wichtig, damit man den Container mit den Standard-Algos nutzen kann. GetSize() ist auch unglücklich, hier wäre size() C++-konformer.
Damit würde die Akzeptanz des Containertyps schneller steigen. Ich würde sowas ungern benutzen.
-
Erstens: Was hindert dich daran, einen vector<> zu verwenden? Normalerweise ist es nicht nötig, das Rad neu zu erfinden.
Zweitens: Du brauchst noch einen Copy-Ctor und operator=, sonst kommst du schnell in Teufels Küche.
Drittens: Eventuell solltest du vorsorglich etwas mehr Speicher anfordern als du für die aktuelle Größe benötigst, dann mußt du die Daten nicht bei jedem add() umkopieren (kann bei größeren Arrays schnell langwierig werden).
Viertens: Ist zwar nur eine Kleinigkeit, aber - nimm Initialisierungslisten:
CDynPtrArray(int size=0) : iSize(size), m_pArray(new T*[size]) {}Fünftens: GetSize() und getAt() kannst du auch als const-Methoden deklarieren - die ändern nichts an deinen Daten (btw, einige dich mal mit dir selbst auf eine einheitliche Schreibweise :D).
-
Naja, vielleicht dient es nur zum Übungszweck? (hoffe ich!) Ansonst kann man auch http://www.boost.org/libs/ptr_container/doc/ptr_container.html benutzen.
-
Für den Fall, das size 0 ist würde ich erst gar keinen Speicher anfordern. Die size-Variable sollte size_t sein.
CDynPtrArray(size_t size=0) : iSize(size), m_pArray(size ? new T*[size] : 0) {}
-
danke für die kritik und verbesserungsvorschläge... Ja ist primär zur übung gedacht... wenn allerdings auf einem system programmiert wird, auf dem keine biblothek vorhanden ist, musst die ja nach diesem Still realistiert werden (nehm ich mal an) ..
Das Problem mit der dynamischen größe könnte ich ja mit einer verketten list umsetzen oder? grüße
-
Könnte man schon. Das kommt jetzt darauf an, wie du dein Array verwenden willst. Wenn wahlfreien Zugriff über einen Indexoperator brauchst ist das eher eine schlechte Idee. Machs doch wie bei std::vector. Alloziere etwas mehr Speicher (z.Bsp. doppelt so viel) und erzeuge neuen wenn du mehr brauchst und kopiere dann um.
-
achso d.h. std::vector reservier immer doppelt soviel sovielspeicher wie nötig ist... wenn der speicher mit "add" dann ausgereitzt ist, wird wieder rum das doppelte vom doppelten reserviert und umkopierT?
-
du überprüfst nie ob die übergebenen Werte io sind ...
-
BorisDieKlinge schrieb:
achso d.h. std::vector reservier immer doppelt soviel sovielspeicher wie nötig ist... wenn der speicher mit "add" dann ausgereitzt ist, wird wieder rum das doppelte vom doppelten reserviert und umkopierT?
Nein, muß der Vector nicht unbedingt. Hängt von der Implementierung ab.