Iterator oder Listenproblem

Ja, ich gebe eine Kopie der Liste zurück. Ich habe schon vermutet, dass das Problem verursacht.

Also passen die Iteratorentupel nicht zusammen?
Was sollte das für Auswirkungen haben?
Irgendwie hätte ich vermutet, dass das Programm dann wenigstens bis zum Ende der Liste durchiteriert, weil iter.begin() und end() nie übereinstimmen und dann irgendwas seltsames tut.
Aber es bricht schon beim ersten Schleifendurchlauf ab.

Und was bedeutet , dass ICH eine Assertion bekomme?
ich kenne assert() aber was Assertion bekommen bedeutet weiß ich leider nicht.

Tachyon

shisha schrieb:

Ja, ich gebe eine Kopie der Liste zurück. Ich habe schon vermutet, dass das Problem verursacht.

Also passen die Iteratorentupel nicht zusammen?
Was sollte das für Auswirkungen haben?
Irgendwie hätte ich vermutet, dass das Programm dann wenigstens bis zum Ende der Liste durchiteriert, weil iter.begin() und end() nie übereinstimmen und dann irgendwas seltsames tut.
Aber es bricht schon beim ersten Schleifendurchlauf ab.

Und was bedeutet , dass ICH eine Assertion bekomme?
ich kenne assert() aber was Assertion bekommen bedeutet weiß ich leider nicht.

Iteratoren sind häufig so implementiert, dass sie im Debugmodus eine Assertion auslösen, wenn irgendetwas nicht zusammen passt.
In Deinem Fall merkt beim Vergleich, dass die Iteratoren nicht vom gleichen Objekt kommen.

Ok, danke soweit. Ich habe noch 2 abschließende Fragen dazu:

1. Wie viele Kopien von der Liste werden tatsächlich erstellt?

Wenn die Bedingung

iter != connections[i].getConnectID().end();

durchgeführt wird, wird da in JEDEM Durchlauf eine neue Kopie erzeugt?
(Wenn man von eventuellen Compiler-Optimierungen absieht)

2. Ist es vom Design her besser Referenzen zurückzugeben?

Ich habe bisher überall Kopien zurückgegeben, aus ANgst dass ich mir meine Einträge versehentlich zerschieße, aber vlt ist es doch günstiger, wenn ich mir den direkten Zugriff ermögliche?

daddy_felix

shisha schrieb:

Ich habe bisher überall Kopien zurückgegeben, aus ANgst dass ich mir meine Einträge versehentlich zerschieße, aber vlt ist es doch günstiger, wenn ich mir den direkten Zugriff ermögliche?

du kannst auch konstante Referenzen zurückgeben...

Bashar

shisha schrieb:

Und was bedeutet , dass ICH eine Assertion bekomme?
ich kenne assert() aber was Assertion bekommen bedeutet weiß ich leider nicht.

Eine Assertion ist eine Behauptung, die man über den Programmzustand an einer bestimmten Stelle macht, mit dem Ziel, dass man über eine falsche Annahme durch einen Abbruch mit Fehlermeldung informiert wird. Das ist dann eine fehlgeschlagene Assertion, schlampig auch einfach nur Assertion genannt. Klarer?

Tachyon

daddy_felix schrieb:

shisha schrieb:

Ich habe bisher überall Kopien zurückgegeben, aus ANgst dass ich mir meine Einträge versehentlich zerschieße, aber vlt ist es doch günstiger, wenn ich mir den direkten Zugriff ermögliche?

du kannst auch konstante Referenzen zurückgeben...

Eigentlich ist es auch gut, Kopien zurückzugeben.
Du kannst es zum Beispiel einfach so machen, wie in Deinem funktionierenden Beispiel.

du kannst auch konstante Referenzen zurückgeben...

Ist das hier Korrekt?

const std::list<int>& CONECT::getConnectionID() const

Habe mit const auch so meine Probleme ^^

Tachyon

shisha schrieb:

du kannst auch konstante Referenzen zurückgeben...

Ist das hier Korrekt?
const std::list<int>& CONECT::getConnectionID() const
Habe mit const auch so meine Probleme ^^

Das hängt davon ab, ob das Listenobjekt, das da referenziert wird, nach dem Funktionsaufruf gültig bleibt.

Direkt nach dem Aufruf ist es normal noch gültig.
Ist es meine Aufgabe so was zu verhindern ?

instanz = new KLASSENTYP();
list<int> l = instanz.getConnectionID();
delete instanz;
beliebiger zugriff auf l

Tachyon

shisha schrieb:

Direkt nach dem Aufruf ist es normal noch gültig.
Ist es meine Aufgabe so was zu verhindern ?
instanz = new KLASSENTYP();
list<int> l = instanz.getConnectionID();
delete instanz;
beliebiger zugriff auf l

Da ist alles okay. l ist eine Kopie dessen, was zurückgegeben wird.
Sowas ist viel schlimmer:

list<int>::iterator i;
{
   KLASSENTYP instanz;
   i = instanz.getConnectionID().begin();
}
int crash = *i;

Da ist alles okay. l ist eine Kopie dessen, was zurückgegeben wird.

Hmm, wenn ich mir das wieder in meinem Iterator-Beispiel reindenke, hätte ich also auch mit dem Ändern des Rückgabetyps auf eine Referenz doch immer noch das Problem dass eine Kopie erstellt wird von der Liste und die Iteratoren nicht zusammenpassen?

Tachyon

shisha schrieb:

Da ist alles okay. l ist eine Kopie dessen, was zurückgegeben wird.

Hmm, wenn ich mir das wieder in meinem Iterator-Beispiel reindenke, hätte ich also auch mit dem Ändern des Rückgabetyps auf eine Referenz doch immer noch das Problem dass eine Kopie erstellt wird von der Liste und die Iteratoren nicht zusammenpassen?

Ohne Dir zu nahe treten zu wollen:
Da Du das mit den Gültigkeiten anscheinend noch nicht so ganz durchdrungen hast, bleibe bei Kopien und mache es so, wie in Deinem ersten Beispiel.
Btw. ist hier nicht der Rückgabewert selbst eine Kopie, sondern l.
In Deinem Beispiel wäre eher das hier problematisch:

instanz = new KLASSENTYP();
list<int> const & l = instanz.getConnectionID(); //l ist jetzt keine Kopie
delete instanz;
beliebiger zugriff auf l

Danke vorerst mal.

Ich habe schon Jahre nichts mehr mit C++ gemacht und habe das bisschen, dass ich mal konnte auch schon fast vergessen.

Musste gerade nochmal "Refenz" nachschauen um wieder festzustellen, dass Referenzen schon als solche deklariert werden müssen und dass der kritische Aufruf, den ich meinte so aussehen müsste, wie eben von dir gepostet.

Es kann mir im Moment durchaus passieren, dass ich den einen oder anderen Anfängerfehler begehe und es nicht mal mehr merke.

Ich hoffe mein nächstes Problem lässt nun auf sich warten