|
Community
Szene & News
Locations
Impressum
|
Forum / Bits und Bytes
std::list → Objekt durch Index bestimmen (Fehler)
WhiteMike 
Fortgeschrittener
(offline)
Dabei seit 05.2005
58
Beiträge
|
|
Geschrieben am: 19.06.2008 um 14:19 Uhr
|
|
So, Leute.
Eigentlich weiß ich nicht, was daran nicht funktionieren kann, aber offensichtlich läuft irgendwas schief.
Was ich will, ist ein Objekt aus einer std::list aus der STL, dessen Index ich angebe. Das ist das, was man ja häuftig macht. Umso unverständlicher ist der Fehler für mich.
Erstmal die Methode:
________________________________________________
// ERROR: Verdacht auf Fehler!
#pragma warning (disable: 4715)
Base_Subject Bank::GetSubject(unsigned int index)
{
assert(index < m_List_Subjects.size());
int k = 0;
for(list<Base_Subject>::iterator it = m_List_Subjects.begin(); it != m_List_Subjects.end(); it++, k++)
{
cout << "--- INDEX: " << (*it).GetID();
if(k == index)
return (*it);
}
assert(false);
}
________________________________________________
Die Liste enthält Objekte (später werde ich es vielleicht doch auf Zeiger umschreiben).
Alledings kann es nichts mit dem Fehler zu tun haben, da nur die Indizes verglichen werden. Was man bekommt, wenn man den Iterator dereferenziert, ist ja nicht entscheidend.
Ich hab mir mal die ID vom Objekt ausgeben lassen, auf das der Iterator in jedem Schleifendurchlauf zeigt und hab mit Erstaunen feststellen müssen, dass es immer die ID des ersten Elements in der Liste ist.
Es ist fast so, als würde der Iterator trotz "it++" nicht vorverschoben werden.
Vielleicht fällt jemandem was ein, der es mit etwas anderen Augen sieht.
Was nicht schaden könnte, ist das Überlegen, ob vielleicht nicht doch etwas außerhalb der Funktion nicht stimmt.
Außerdem bin ich für Verbesserungen sonstiger Art ebenfalls sehr dankbar (Stichwörter: Ausnahmesicherheit, Performance, ...).
Mit freundlichen Grüßen, WhiteMike.
|
|
-_neu - 31
Halbprofi
(offline)
Dabei seit 05.2008
198
Beiträge
|
|
Geschrieben am: 19.06.2008 um 14:36 Uhr
|
|
Die Liste enthält Objekte (später werde ich es vielleicht doch auf Zeiger umschreiben).
Alledings kann es nichts mit dem Fehler zu tun haben, da nur die Indizes verglichen werden. Was man bekommt, wenn man den Iterator dereferenziert, ist ja nicht entscheidend.
Ich hab mir mal die ID vom Objekt ausgeben lassen, auf das der Iterator in jedem Schleifendurchlauf zeigt und hab mit Erstaunen feststellen müssen, dass es immer die ID des ersten Elements in der Liste ist.
Es ist fast so, als würde der Iterator trotz "it++" nicht vorverschoben werden.
Vielleicht fällt jemandem was ein, der es mit etwas anderen Augen sieht.
Was nicht schaden könnte, ist das Überlegen, ob vielleicht nicht doch etwas außerhalb der Funktion nicht stimmt.
Außerdem bin ich für Verbesserungen sonstiger Art ebenfalls sehr dankbar (Stichwörter: Ausnahmesicherheit, Performance, ...).
Großer Erfolg!!!
|
|
McPommes - 51
Experte
(offline)
Dabei seit 09.2006
1422
Beiträge
|
|
Geschrieben am: 19.06.2008 um 17:10 Uhr
|
|
Was soll der zweite Beitrag?!
Mit Iteratoren in C++ kenn ich mich zwar nicht aus, aber ich würd mir mal den tatsächlichen Wert des Iterators ausgeben lassen, dann siehst du ob der hochgezählt wird oder nicht.
Vielleicht stimmt ja mit GetID auch irgendwas nicht, dass da das gleiche zurück kommt.
Was ich auch ein bisschen schräg finde, warum muss man so lange weiterzählen bis der Index erreicht ist? Kann man da nicht direkt über den Index zugreifen?
*** diese Fusszeile verschwendet 45 Bytes ***
|
|
WhiteMike
Fortgeschrittener
(offline)
Dabei seit 05.2005
58
Beiträge
|
|
Geschrieben am: 19.06.2008 um 21:18 Uhr
|
|
Zitat von McPommes: Was soll der zweite Beitrag?!
Mit Iteratoren in C++ kenn ich mich zwar nicht aus, aber ich würd mir mal den tatsächlichen Wert des Iterators ausgeben lassen, dann siehst du ob der hochgezählt wird oder nicht.
Vielleicht stimmt ja mit GetID auch irgendwas nicht, dass da das gleiche zurück kommt.
Was ich auch ein bisschen schräg finde, warum muss man so lange weiterzählen bis der Index erreicht ist? Kann man da nicht direkt über den Index zugreifen?
Ich weiß auch nicht, was der Beitrag von vorhin soll.
Der Fehler lag wirklich an einer anderen Stelle - nämlich bei dem Füllen der Liste mit den Daten.
Ich finde es auch witzig, dass die STL-Liste den []-Operator nicht überladen hat. Bei einer Liste muss man sich also durchhangeln.
Inzwischen hab ich sie aber doch durch einen std::vector ersetzt, mit dem das möglich ist. Man kann sich vorstellen, dass der Code so viel besser aussieht. 
Danke für Deine Hilfe. :)
Mit freundlichen Grüßen, WhiteMike.
|
|
Polaris
Experte
(offline)
Dabei seit 07.2006
1766
Beiträge
|
Geschrieben am: 19.06.2008 um 22:55 Uhr
Zuletzt editiert am: 19.06.2008 um 22:55 Uhr
|
|
Zitat von WhiteMike:
Ich finde es auch witzig, dass die STL-Liste den []-Operator nicht überladen hat. Bei einer Liste muss man sich also durchhangeln.
Inzwischen hab ich sie aber doch durch einen std::vector ersetzt, mit dem das möglich ist. Man kann sich vorstellen, dass der Code so viel besser aussieht.
Aussehen hin oder her.
Alles hat seine Vor- und Nachteile.
Ein std::vector ist wahnsinnig schnell, wenn man auf bestimmte Positionen (per Index) zugreifen muss bzw sich durchiterieren will, weil es intern im Speicher eben ein zusammenhängendes Array ist. Dafür dauern Einfüge- und Löschoperationen deutlich länger, da erst das Array umgeschichtet / umgebaut werden muss, wohingegen in einer (doppelt) verketteten Liste eben nur ein paar Zeiger verändert werden müssen.
Patriotismus ist die Tugend der Bosheit! (Oscar Wilde)
|
|
WhiteMike
Fortgeschrittener
(offline)
Dabei seit 05.2005
58
Beiträge
|
|
Geschrieben am: 19.06.2008 um 23:05 Uhr
|
|
Zitat von Polaris: Zitat von WhiteMike:
Ich finde es auch witzig, dass die STL-Liste den []-Operator nicht überladen hat. Bei einer Liste muss man sich also durchhangeln.
Inzwischen hab ich sie aber doch durch einen std::vector ersetzt, mit dem das möglich ist. Man kann sich vorstellen, dass der Code so viel besser aussieht.
Aussehen hin oder her.
Alles hat seine Vor- und Nachteile.
Ein std::vector ist wahnsinnig schnell, wenn man auf bestimmte Positionen (per Index) zugreifen muss bzw sich durchiterieren will, weil es intern im Speicher eben ein zusammenhängendes Array ist. Dafür dauern Einfüge- und Löschoperationen deutlich länger, da erst das Array umgeschichtet / umgebaut werden muss, wohingegen in einer (doppelt) verketteten Liste eben nur ein paar Zeiger verändert werden müssen.
Das ist schon richtig. So ist es auch verständlich, warum die Listen doch keinen Zugriff per Indexwert erlauben. Etwas blöd ist es nur, wenn man das ganze selbst implementieren muss, aber dann ist man vielleicht auch selbst schuld.
Mit freundlichen Grüßen, WhiteMike.
|
|
Forum / Bits und Bytes
|
[