MFC Container -> STL
-
Hallo!
Ich habe ein bestehendes Projekt in dem MFC-Container (CArray, CMap, etc...) verwendet werden. Nun hab ich vor diese durch STL-Container zu ersetzen. Ich möchte/muss aber auch die alte Funktionalität beibehalten, d.h. es soll per define zwischen den beiden Welten gewechselt werden können. Für die Datentype hab ich mir da folgendes überlegt:
#if defined COMP_WITH_STL typedef std::vector <MyType> DataArray; #else typedef OCArray <MyType> DataArray; #endif
Bei den Funktionsparametern/Membervariablen usw. ist das ja ok. Nur hab ich natürlich auch noch die ganzen Funktionsaufrufe, die bisher die MFC-Container nutzten.
for(int i = 0; i <= data.GetUpperBound(); i++){ // bla }
Wenn ich mit COMP_WITH_STL kompiliere gibt das natürlich ein Problem, weil die Funktion im STL-Container anders heißt. Wie würdet ihr da vorgehen? Makros schreiben? Vom STL-Vector ableiten und mir die fehlenden Funktionen einbauen?
Danke für eure Tipps!
-
Ich würde einen Wrapper schreiben. Vererbung ist hierfür völlig falsch, der vector hat keinen virtuellen Desruktor. Ist aber auch nicht das einzige Problem.
Schreib eine Wrapper-Klasse, die einen vector als Member hat und die Funktionen an ihn weiterleitet.
-
Ok, gute Idee. Was hälst du von diesem Ansatz?
template <class TYPE> class AxSTLWrapper { public: void Add(TYPE newElement){ arr.push_back(newElement); } INT_PTR GetUpperBound() const{ return arr.size() - 1; } void RemoveAll(){ arr.clear(); } const TYPE& operator[](INT_PTR nIndex) const{ return arr[nIndex]; } TYPE& operator[](INT_PTR nIndex){ return arr[nIndex]; } private: std::vector<TYPE> arr; };
-
Add sollte einen const TYPE& nehmen, außerdem kommt es mir etwas seltsam vor, dass du als Typ für den Index-Operator INT_PTR nimmst.
Abgesehen davon bin ich kein Freund von gecapsten Template-Parametern, ist aber wohl Geschmackssache.
Ansonsten sieht das recht brauchbar aus.
-
Das mit dem const hab ich auch schon bemerkt. der INT_PTR ist aus Kompatibilität mit der CArray-Implementierung.
Danke!
-
Source2702 schrieb:
Wenn ich mit COMP_WITH_STL kompiliere gibt das natürlich ein Problem, weil die Funktion im STL-Container anders heißt. Wie würdet ihr da vorgehen?
Also ich würde das ganz vermeiden wenns irgendwie geht. D.h. Umstieg auf SCL Klassen und aus, kein Support der MFC Klassen mehr.
Aber wenns unbedingt sein muss...
Makros schreiben? Vom STL-Vector ableiten und mir die fehlenden Funktionen einbauen?
Nönönö.
Ich denke freie überladene Funktionen bzw. Funktions-Templates wären ne nette Sache.template <class T> size_t get_size(std::vector<T> const& vec) { return vec.size(); } template <class T> size_t get_size(CArray<T> const& arr) { return arr.GetSize(); } // ... for(int i = 0; i <= get_size(data); i++){ // bla }
Das werden u.U. halt recht viele werden, aber naja, ...
-
Das werden u.U. halt recht viele werden, aber naja, ...
Hat sich in Grenzen gehalten - zumindest bei mir. Kompiliert schon durch. Hier die komplette Klasse sollte mal jemand so was brauchen.
template <class TYPE> class AxSTLWrapper { public: void Add(const TYPE& newElement){ arr.push_back(newElement); } INT_PTR GetUpperBound() const{ return arr.size() - 1; } INT_PTR GetSize() const{ return arr.size(); } INT_PTR GetCount() const{ return GetSize(); } void RemoveAll(){ arr.clear(); } void SetAt(INT_PTR nIndex, const TYPE& newElement){ arr[nIndex] = newElement; } void InsertAt(INT_PTR nIndex, const TYPE& newElement, INT_PTR nCount = 1){ arr.insert(arr.begin() + nIndex, newElement); } void RemoveAt(INT_PTR nIndex, INT_PTR nCount = 1){ arr.erase(arr.begin() + nIndex); } const TYPE& operator[](INT_PTR nIndex) const{ return arr[nIndex]; } TYPE& operator[](INT_PTR nIndex){ return arr[nIndex]; } private: std::vector<TYPE> arr; };