ich arbeite mit dem KlassenTemplate CArray. ok, nun möchte ich aber ein object dieser klasse an eine funktion übergeben, bekomme aber immer folgenden fehler:

"konvertierung von 'class CArray <class CString,class CString>' in 'class CArray <class CString,class CString>' nicht möglich"

also, wo bitte ist da der fehler? die typen sind doch beide gleich.

definition des arrays:
CArray <CString,CString> myarray;

soll ich nun die typdefinition des templates <CString,CString> auch bei dem Prototypen, und oder bei der Implementierung, und oder bei dem Aufruf der Funktion angeben..wenn ja, wie soll es aussehen?

hoffe jemand versteht mein Problem.
danke, dAVEdIGITAL

Bitte poste einen minimalen Code, der das Problem aufweist.

Hast Du wirklich die ganze Fehlermeldung gelesen? Glaube nicht!
NO COPYCONSTRUCTOR AVAILABLE erhalte ich wenn ich das Array in einer Funktion übergeben will!

Lösung: Du musst die das Objekt als Referenz übergeben, dann klappts******
Noch was! Es gibt bereits eine Klasse die nennt sich CStringArray! Also musst Du den Typ nicht neu definieren!

So müsste Dein Problem behoben sein:

Code :

1 2 3 4 5 6 7 8 9 10

void CTestApp::Test() {     CStringArray myarray;     MeineFunktion(myarray); }   void CTestApp::MeineFunktion(CStringArray &myArray) {     myArray.Add(_T("Hallo")); }

Übrigens sind die STL-Container wesentlich besser und die Copy-Konstruktoren sind auch nciht als private/protected deklariert ..

Da habe ich aber was anderes gehört****** Diese seien weniger effizient implementiert als die der MFC!

Und nochwas: Versuche mal bei STL Listcontainer ein RemoveAt() zu machen****** So einfach wie bei der MFC geht das mit der STL nicht!

Das die - übrigens proprietären - MFC Container effizienter sind glaub ich nicht. ( -> beweisen ?)

RemoveAt sagt mir nichts (und brauch es auch nicht). Wenn du das Löschen eines Elements meinst, so sehe ich kein Problem damit.

Außerdem sind die Standard C++ Library Container äußerst generisch gehalten (Stichwort: Iteratoren), so dass du z.b. die selben Algorithmen mit jedem beliebigen Container (dazu zähl übrigens auch das builtin Array) verwenden kannst.

Die MFC Container wurden vor der Standarisierung von C++ geschaffen und sind wesentlich eingeschränkter als die STL/Standard C++ Library Container.

Bevor wir nun darüber ins endlose diskutieren, ob die STL Container besser sind als die der MFC lass es mich so ausdrücken!

- Ist es angebracht, wenn man mit der MFC arbeitet auf STL-Container zurückzugreifen? Macht dies Sinn? Denke nein!
- Vorteil der MFC Container ist, dass diese Vorteile bieten, was STL-Container nicht aufweisen: Einfachere Handhabung, Serialisierung!

In diesem Sinne! Soll jeder das verwenden was er für besser hält!
Verwende STL nur wenn ich rein in C++ programmiere! Bei der Programmierung mit der MFC greife ich zuerst auf die Klassen der MFC zurück!

Die MFC-Container sind eben nicht einfacher handzuhaben und weisen, wie wir gesehen haben einige gravierende Lücken auf (ein Container mit private Copy-Constructor? -> sinnlos).

Außerdem ist die MFC sowieso "überfüllt" und kaum mehr sinnvoll brauchbar.

Lässt Du dann die MFC links liegen - auch bei Oberflächen? Machst Du alles mit der STL bzw. WTL?

Für alles was die STL kann - STL

Wenn ich graphicse Oberflächen brauche nehm ich für einfaches (und Windows) WinAPI, einfache (und XWindows) - Xlib (d.h. z.b. wenn ich nur ein Fenster für OpenGL / DirectX brauch).

Für komplexe graphische Oberflächen -> Qt.
Bis auf den proprietären Präprozessor, mit dem sie SIGNALS/SLOTS implementieren ist Qt wesentlich sauber und eleganter als die MFC (-> auch weniger Code )

So ihr beiden Streithähne nach dem ihr euch einig seit, was besser ist MFC oder STL will ich euch noch nen 3. im Bunde der Templates nahlegen. Ich weiß nicht ob irgendjemand da draußen schon mal damit was gemacht hat oder nicht. Ist das der Fall, dann würde ich mich auch mal über Erfahrungen freuen.

Die Rede ist von Rougewave-Libraries.
Die Container, die da angeboten werden sind meiner Meinung nach nicht von schlechten Eltern. Ok die LIB's sind nicht mehr ganz taufrisch und werden zudem, auch nicht mehr supported (leider) aber wer mal damit gearbeitet hat, der kann dem schon etwas abgewinnen.
Für GUI gibt es da zFactory, das ist ein Eigenständiges Entwicklungstool um GUI zu erstellen und dann die ganzen Dateien zu generieren, dagegen ist meiner Meinung nach der App-Wizard von VC++6.0 schlecht. Denn der Code der prodiziert wird ist sehr übersichtilich und enthält auch nur das nötigste.
Und ein weiterer Pluspunkt des ganzen ist, die Portierbarkeit auf UNIX.

Gruss Homer (der privat auch mit der MFC rumbastelt und sie net schlecht findet)

Original geschrieben von homer
So ihr beiden Streithähne nach dem ihr euch einig seit, was besser ist MFC oder STL will ich euch noch nen 3. im Bunde der Templates nahlegen. Ich weiß nicht ob irgendjemand da draußen schon mal damit was gemacht hat oder nicht. Ist das der Fall, dann würde ich mich auch mal über Erfahrungen freuen.

Ich möchte mal klarstellen, dass wir MFC Container & STL Container verglichen haben, nicht die gesamten Libraries, da man unmöglich Libraries vergleichen kann, die etwas vollkommen anderes machen.

Die Rede ist von Rougewave-Libraries.
Die Container, die da angeboten werden sind meiner Meinung nach nicht von schlechten Eltern. Ok die LIB's sind nicht mehr ganz taufrisch und werden zudem, auch nicht mehr supported (leider) aber wer mal damit gearbeitet hat, der kann dem schon etwas abgewinnen.

Die Library die du ansprichst ist AFAIK die Roguewave Implementierung der Standardlibrary (eine weitere gute Implementierung wäre z.b. Dinkumware; STLPort (bzw. SGI STL) ist ebenfalls empfehlenswert) - eben nur eine Implementierung der in ISO 14882:1998 festgelegten Library

Für GUI gibt es da zFactory, das ist ein Eigenständiges Entwicklungstool um GUI zu erstellen und dann die ganzen Dateien zu generieren, dagegen ist meiner Meinung nach der App-Wizard von VC++6.0 schlecht. Denn der Code der prodiziert wird ist sehr übersichtilich und enthält auch nur das nötigste.
Und ein weiterer Pluspunkt des ganzen ist, die Portierbarkeit auf UNIX.

Gruss Homer (der privat auch mit der MFC rumbastelt und sie net schlecht findet)

Naja, eigentlich geht's um GUI-Libraries nicht um Tools (Qt hätte da auch z.b. den Qt Designer, der das selbe macht) - Qt ist übrigens auch plattformunabhängig

Haben wir gestritten Xeragon?
Also ich habe es nicht so empfunden! Sachlich diskutiert! Letztendlich kommt es ja darauf an, an welchem Projekt man arbeitet und in wie weit es Plattformübergreifend ist!

Steige wahrscheinlich sowieso um auf .NET (sind da die Container besser als die in der STL? )

Nein, wir haben nicht gestritten

Wegen der .NET Container: Wenn du .NET in C++ machst kannst du noch immer die STL verwenden ... ansonsten.. wenn du die "richtigen" .NET COntainer oder Java Container verwenden musst ... viel Spaß, zumindest wirst du dann templates (die dann nicht vorhanden sind) zu schätzen lernen .

Anders ausgedrückt: Da die meisten anderen Sprachen keine templates haben, werden generische, typsichere Container zu einer Qual (für jeden Typ einzeln spezialisieren )