STL list und der gescheiterte zugriff

spjoe

es gehört rein weil er

std::list <DiagonalRun*> drList;

macht.
Ich weis zwar nicht warum er nur eine pointer liste haben will, aber das ist seine sache. Ich würde es so machen

std::list <DiagonalRun> drList;

mfg

CarstenJ

Hallo,

zumal er ja dann auch für jedes Objekt delete aufrufen muss, sonst gibts nen Problem. Wenn natürlich polymorphes Verhalten benötigt wird, wird ein Zeiger notwendig.

Shade Of Mine

Nur hat ein Zeiger in einer liste IMHO nur sehr selten bis nie etwas zu suchen.

Denn man hat Ploetzlich 200% overhead durch den prev und next zeiger.

Das ist doch arg viel. ausserdem ist die daten lokalitaet dann ja auch ganz im hintern ich wuesste keine situation wo ein pointer vector schlechter als eine pointer liste waere...

finix

cout<<(*dr_iter)->startx<<" , "<<(*dr_iter)->starty<<"\t";

Shade Of Mine schrieb:

ich wuesste keine situation wo ein pointer vector schlechter als eine pointer liste waere...

Vielleicht in Situationen wo ein vector schlechter wäre als eine Liste?

spjoe

@finix lol

anonymus

cout<<(*dr_iter).startx<<" , "<<(*dr_iter).starty<<"\t";

*dr_iter liefert doch einen Zeiger?

Dann müsste es doch so heissen (mit Pfeil):

cout<<(*dr_iter)->startx<<" , "<<(*dr_iter)->starty<<"\t";

Wär sowas nicht ein Fall für Zeiger in einer Liste?

while ( holDaten() )
{
// mach mir ne Struktur im Heap und
// rein mit der Adresse in die Liste
}

Ist doch Schneller, als wenn man erst die Struktur lokal baut
und dann in die Liste reinkopiert??

stillsen

tja ihr hattet wohl alle recht....
der zeiger ist überflüssig und wurde entfernt.

@anonymus: recht hast du, zeiger auf zeiger

danke @ all

Shade Of Mine

finix schrieb:

Vielleicht in Situationen wo ein vector schlechter wäre als eine Liste?

Aber bedenke: da wir nur Zeiger speichern, ist die schlechte laufzeit von vector beim einfuegen in der mitte dennoch nicht so lahm.

wir muessten also von unmengen an daten ausgehen, die alle in der mitte eingefuegt werden.

oder aber iteratoren duerfen nicht ungueltig werden.

beides keine bedingungen die wirklich so oft vorkommen.

ssm

Shade Of Mine schrieb:

ich wuesste keine situation wo ein pointer vector schlechter als eine pointer liste waere...

1. vector hat keine slice Methode
2. insert && remove operations from list müssten schneller sein, wenn man viel Elementen im container hat

finix

Shade Of Mine schrieb:

Aber bedenke: da wir nur Zeiger speichern, ist die schlechte laufzeit von vector beim einfuegen in der mitte dennoch nicht so lahm.

wir muessten also von unmengen an daten ausgehen, die alle in der mitte eingefuegt werden.

Mag schon stimmen das in vielen Fällen der vector ebenso geeignet oder gar sinniger ist; aber sobald du viele - im Sinne von häufigen - insert- oder remove- oder gar splice-operationen hast würde ich persönlich schon wieder zur list tendieren.

Davon ab hast du auch beim vector im Zweifelsfalle an die 100% Overhead

Läuft halt oft auf die bekannte Abwägung Speicher/Laufzeit hinaus...

Shade Of Mine

finix schrieb:

Davon ab hast du auch beim vector im Zweifelsfalle an die 100% Overhead

Und wie?

Läuft halt oft auf die bekannte Abwägung Speicher/Laufzeit hinaus...

Nicht nur.

finix

Shade Of Mine schrieb:

finix schrieb:

Davon ab hast du auch beim vector im Zweifelsfalle an die 100% Overhead

Und wie?

vector<int> test(100, 42);
cout << test.capacity() << endl;
test.push_back(43);
cout << test.capacity() << endl;

Dieser Schnipsel gibt bei mir zuerst 100, dann 200 aus. Soweit ich mich entsinne ist das wohl abhängig von der Implementation (hab den Standard nicht auswendig gelernt ), aber wenn du solche Effekte nicht hast dann wirst du, unter gegebenen (und zwar häufig gegebenen) Umständen, in Bezug auf die Laufzeit einbußen hinnehmen müssen.

[quote="Shade Of Mine"]

finix schrieb:

Läuft halt oft auf die bekannte Abwägung Speicher/Laufzeit hinaus...

Nicht nur.

Ich habe gar nicht bestreiten wollen dass dein Hinweis u.U. das absolut sinnvollste sein kann. Sind uns vielleicht nicht ganz über die Häufigkeit solcher Umstände einig..
Falls das "Nicht nur" nicht auf die Häufigkeit oder die generelle Existenz solcher Fälle abzielt würde ich mich gerne aufgeklärt wissen

Shade Of Mine

finix schrieb:

Dieser Schnipsel gibt bei mir zuerst 100, dann 200 aus. Soweit ich mich entsinne ist das wohl abhängig von der Implementation (hab den Standard nicht auswendig gelernt ), aber wenn du solche Effekte nicht hast dann wirst du, unter gegebenen (und zwar häufig gegebenen) Umständen, in Bezug auf die Laufzeit einbußen hinnehmen müssen.

Normalerweise verwendet man hier den Faktor 0.5 zum wachsen, aber ok.

der trick ist aber: du brauchst idr keine reallokationen, weil du dank reserve() die exakte menge bestimmen kannst.

Falls das "Nicht nur" nicht auf die Häufigkeit oder die generelle Existenz solcher Fälle abzielt würde ich mich gerne aufgeklärt wissen

"nicht nur", weil es eben auch auf Datenlokalitaet, komplexitaet der operationen (insert, remove, slice,...) usw. ankommt.
dh: mehr speicher muss nicht unbedingt schneller bedeuten.
mehr wollte ich nciht sagen.

finix

Shade Of Mine schrieb:

der trick ist aber: du brauchst idr keine reallokationen, weil du dank reserve() die exakte menge bestimmen kannst.

hmm. Ich denke der "Trick" dürfte hinlänglich bekannt, aber in Fällen wo man (zumindest näherungsweise) weiß wie viele Elemente reinsollen und sich das nicht oder nur selten ändert ist der vector in der Tat die bessere Alternative, zumeist wohl nicht nur für Pointer.

"nicht nur", weil es eben auch auf Datenlokalitaet, komplexitaet der operationen (insert, remove, slice,...) usw. ankommt.
dh: mehr speicher muss nicht unbedingt schneller bedeuten.
mehr wollte ich nciht sagen.

Natürlich. Datenlokalität ist ein guter Punkt. In Bezug auf die Komplexität der Operationen würde ich behaupten dass wenn man die angesprochenen Operationen benötigt mehr Speicher schon schneller bedeutet - wenn nicht ist der Speicher ohnehin eher planlos verschwendet

So gesehen hast du Recht, diese Fälle habe ich dir ja auch nicht bestritten - eine Regel würde ich trotzdem nicht unbedingt draus machen