Fehler bei Ausgabe mittels iterator von vector<*eigeneKlasse>

[butterbemme]

Hiho,

folgendes Problem:
ich habe meinen vector<Karte*> hauptKartendeck dessen 32 Zeiger auf verschiedene Instanzen der Klasse Karte ein Kartendeck repräsentieren.
Um mir die Ausgabe der verschiedenen Karten zu erleichtern, hab ich für die Klasse Karte den operator<< überladen.
Das sieht dann alles so aus:
karte.cpp

...
std::ostream& operator<<(std::ostream& lhs, Karte const& ka){
        lhs << ka.getFarbe() << " " << ka.getZahl();
}
...

Funktion um Kartendeck auszugeben:
spielleiter.cpp

void Spielleiter::printHauptKartendeck(){
    vector<Karte*>::const_iterator ci=hauptKartendeck.begin();
    cout << "HauptKartendeck: " << endl;
    for(ci;ci!=hauptKartendeck.end();ci++){
        //cout << (*ci)->getFarbe() << ' ' << (*ci)->getZahl() << endl;
        cout << **ci << endl;     
    }
}

Mit der auskommentierten Zeile hab ich vorher alle Karten ausgegeben, aber jetzt würd ich gerne den operator<< benutzen.

Immer wenn ich die Funktion "printHauptKartendeck()" aufrufe wird die erste Karte des Kartendecks noch passend ausgegeben, danach hängt sich das Programm auf. Ich schätze mal es hat irgendwas mit dem Iterator zu tun, dass der irgendwo hinzeigt, verstehe aber nicht ganz warum.

edit:
hab den Fehler grade gefunden. Es liegt an dem "endl" am Ende meiner Ausgabe. Wie muss meine operator<< Funktion denn ausschauen damit ich "endl" verwenden kann??

[Sone]

Nein.
Das hier:

std::ostream& operator<<(std::ostream& lhs, Karte const& ka){ 
        lhs << ka.getFarbe() << " " << ka.getZahl(); 
}

Ist falsch, denn du gibst die Stream-Referenz nicht zurück.
So ist es richtig.

std::ostream& operator<<(std::ostream& lhs, Karte const& ka){ 
        return lhs << ka.getFarbe() << " " << ka.getZahl(); 
}

[Sone]

Was mir zu deinem Code-Stil auffällt:

• Du brauchst kein dynamisches, sondern ein statisches Array, da du (so implizierst du es zumindest) eine feste Anzahl von Feldelementen hast.
  Ich empfehle std::array<Karte*, 32> .
• Du benutzt Zeiger? Ich hoffe, das hat einen sehr guten Grund. Denn ich befürchte schon schlimmes. Wieso kein Stackobjekt? Sprich: Wieso lässt du den Container nicht die Karten besitzen?
• for(ci; ... ; ...) Das ci im init-statement ist nur unnötig.
• Möchtest du Spielleiter::printHauptKartendeck nicht Stream-Unabhängig machen? So kannst du dann überall hin serialisieren, auch in Dateien usw.

[butterbemme]

ja klar, was ein dummer Leichtsinnsfehler. Danke für deine Antwort.
Das ist das erste mal, dass ich operator<< überlade. Da mir nich klar war, worans liegt hab ich alle möglichen Versionen ausprobiert und irgendwann hab ich wohl mal das "return" gelöscht

[butterbemme]

Sone schrieb:

Was mir zu deinem Code-Stil auffällt:

• Du brauchst kein dynamisches, sondern ein statisches Array, da du (so implizierst du es zumindest) eine feste Anzahl von Feldelementen hast.
  Ich empfehle std::array<Karte*, 32> .

Du hast Recht, das Kartendeck besitzt eine feste Anzahl an Karten. Die Klasse Spielleiter besitzt aber noch einen weiteren vector<Karte*>, das variable Kartendeck, welcher bei jeder Spielrunde seine Anzahl verändert (Karten austeilen/ziehn etc). Um das variable Kartendeck am Anfang jeder neuen Runde wieder mit allen Karten zu initialisieren, hab ich mich dazu entschlossen das statische hauptKartendeck auch dynamisch zu gestalten, damit ich beide Kartendecks gleich handhaben kann und sie den gleichen Typ besitzen

Sone schrieb:

• Du benutzt Zeiger? Ich hoffe, das hat einen sehr guten Grund. Denn ich befürchte schon schlimmes. Wieso kein Stackobjekt? Sprich: Wieso lässt du den Container nicht die Karten besitzen?

Hat eigentlichen keinen besonderen Grund, mir war danach

Sone schrieb:

• for(ci; ... ; ...) Das ci im init-statement ist nur unnötig.

jap stimmt, das ist mir auch schon aufgefallen und wird noch ausgebessert

Sone schrieb:

• Möchtest du Spielleiter::printHauptKartendeck nicht Stream-Unabhängig machen? So kannst du dann überall hin serialisieren, auch in Dateien usw.

Das verstehe ich nich ganz, wie ist das gemeint?

edit: ich bin für konstruktive kritik offen

[Sone]

Das verstehe ich nich ganz, wie ist das gemeint?

Du nimmst als Parameter eine Referenz auf einen ostream , und benutzt dann statt cout diese Referenz.
Damit kannst du das ganze dann ein wenig flexibler gestalten. :xmas2:

Hat eigentlichen keinen besonderen Grund, mir war danach

Das, ist gar nicht gut.

[butterbemme]

Ist die Referenz auf einen ostream, denn nicht eine Referenz auf cout?
Der Aufruf von

cout << 4;

ist doch gleichzusetzen mit

operator<<(cout,4);

oder?
Wie sollte dann deiner Meinung nach operator<< aussehen?

Zu den Zeigern:
Was spricht gegen den vector voller Zeiger?

[Sone]

Was spricht gegen den vector voller Zeiger?

Das zu beantworten, da habe ich jetzt echt keinen Bock mehr drauf.
Es kommt gleich jemand, der macht das :xmas1:

butterbemme schrieb:

Ist die Referenz auf einen ostream, denn nicht eine Referenz auf cout?

Nein. cout ist ein ostream . Eine Referenz auf einen ostream kann eine Referenz auf cout sein, muss aber nicht.

butterbemme schrieb:

Der Aufruf von

cout << 4;

ist doch gleichzusetzen mit

operator<<(cout,4);

oder?

Fast. Für das schreiben von Skalaren ist der Operator als Member deklariert:

std::cout.operator<<(4);

butterbemme schrieb:

Wie sollte dann deiner Meinung nach operator<< aussehen?

So wie der Standard es festlegt? Das ist IMO schon gut. :xmas2:

[butterbemme]

Ich glaube mir ist schon klar, worauf der Kritikpunkt mit den Zeigern hinausläuft. Größere Fehleranfälligkeit, größeres Fehlerpotential, Fehler schwieriger zu finden usw.
Meine Frage bezog sich auch eher auf Designaspekte, was also in der Hinsicht gegen Zeiger spricht?
Da hab ich mich nicht klar ausgedrückt

[Sone]

Ich glaube mir ist schon klar, worauf der Kritikpunkt mit den Zeigern hinausläuft. Größere Fehleranfälligkeit, größeres Fehlerpotential, Fehler schwieriger zu finden usw.
Meine Frage bezog sich auch eher auf Designaspekte, was also in der Hinsicht gegen Zeiger spricht?

Genau das was du aufgezählt hast...