spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »"Ba'el"«

(kannst du mal den Code deiner "Test-Main" posten will ma' meine Testen)

Ogott! Den Code hab ich gleich nach dem Test wieder aus dem Projekt geschmissen, sorry!

Aber du kannst dir ja, vermutlich, recht schnell selbst was schreiben!

Sieht eigentlich recht gut aus.

Aber in der Formatierung muss ich meinen Vorpostern Recht geben.

Zitat

while(this->m_first!=NULL)

Ein paar Abstände mehr würden nicht schaden.

Und ich weiss ja nicht, wie du das siehts, aber ich finde diese Überprüfung auf NULL recht umständlich. (Aber rein mein Geschmack).

Zitat von »"david_pb"«

Hab mal einen schnellen Vergleich meiner Implementation mit std::list<> gemacht.

Kannst du denn den Code auch mal posten?
Und noch etwas: Implementation gibts nicht in Deutsch. Wenn schon Implementierung. (Ist mir im Eifer des Gefechs auch schon mal unter die Finger gekommen. )

Zitat von »"Ba'el"«

@Deviloper
wenn du mir jetzt noch sagst was genau du mit explizit meinst ... wenn du das meinst was ich darunter verstehe dann ist er doch explizit

Versuchs nochmal so wie Deviloper es geschrieben hat (c statt z) in einer Auflistung von C++ Schlüsselworten, bei google oder sonstwo zu finden :roll:

Zitat von »"Ba'el"«

@David_pb
die std::list<> ist ja wirklich lahm, ich habe push-/popFront(), push-/popBack() getestet da ist meine Implementierung 10x so schnell :oops:
aber wie kann man bei der std::list<> den Iterator abstellen?

Falls es noch Erklärungsbedarf gibt, haben wir hier etwas gemacht:

http://www.scienceandcode.org/?p=46

Ich antworte mal als Kommentar auf den Link ueber mir.

In der Tabelle mit dem Performancevergleich steht bei Arrays und Suchen O(n log n). Das ist falsch! Nur bei einer geordneten Menge stimmt das. Leider habe ich auch keine sinnvolle Anwendung fuer zirkulaere Listen gefunden. Einzig und allein das Bild ist schoen, erinnert an Benzol. Und der Geschwindigkeitsvergleich zwischen java.util.LinkedList, std::list und einer eigenen Implementation hinkt natuerlich, da viel vom Compiler, den einzelnen Flags und der Template Unterstuetzung abhaengt. Desweiteren ist z.B. std::list<> jahrelang getestet und persoenlich wuerde ich diese einer eigenen Implementation vorziehen.

Es gibt natuerlich kaum noch einen Grund, Listen selbst zu schreiben. Vielleicht wenn man sie als synchronisierte Container verwenden will, um dem Producer-Consumer Problem zu begegnen beim Einsatz von lock-free Algorithmen. Aber das ist auch nicht gerade leicht zu realisieren.

Zitat von »"knivil"«

In der Tabelle mit dem Performancevergleich steht bei Arrays und Suchen O(n log n). Das ist falsch!

Da hast du dich verlesen. Da steht O(log n) und das ist korrekt, da man Objekte sortiert in die Liste einfügen kann, wenn man ohnehin schon O(n) Einfügekosten hat. Die Analyse ist also aus der Sicht "Pro-Array" geschrieben.

Zitat von »"knivil"«

std::list<> jahrelang getestet und persoenlich wuerde ich diese einer eigenen Implementation vorziehen.

Würde ich nicht. Die STL ist langsam. Die Syntax ist hässlich. Wenn's 'n dreckiger Quicky sein muß, dann kann man's natürlich nehmen, aber sonst... Naja, ist Geschmackssache

Zitat von »"knivil"«

Es gibt natuerlich kaum noch einen Grund, Listen selbst zu schreiben.

Das ist definitiver als definitiv davon abhängig was man macht und als Pauschalaussage nicht wirklich zutreffend.

Ok, das O( n log n) war ein Tipfehler von mir. Leider steht in dem Artikel nichts in der Zusammenfassung von Sortieren. Und was ist, wenn die eingefuegten Objekte sich nichtmal vergleichen lassen (bzw. das keinen Sinn macht)?