spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

ja sicher. aber ich finde das leichter und schneller zu schreiben (sehr triviales beispiel):




Im gegensatz dazu:





ausserdem wird meines wissens beim anlegen einer instanz der templateklasse eine konkrete klasse des Templatetypen angelegt - ist doch für solch kleinvieh bissl aufgebläht oder?

Naja, der Vorteil des Iterator Interfaces ist es, dass man sämtliche Standardalgorithmen aus der STL damit benutzen kann.

Das Anlegen der konkreten Klasse würde ich mehr oder weniger vernachlässigen. Das vergrößert ja ansich nur die ausführbare Datei, und macht das Compilieren etwas langsamer, aber an der Ausführgeschwindigkeit ändert sich ja nichts und auch der Speicherverbrauch pro Objekt dieser konkreten Klasse Objekt bleibt gleich.

Die Einträge in Vektoren können ja auch primitive Typen sein. Und wieso ist es manchmal schlimm, wenn man die Größe ändern kann? Klar, man verbraucht eine Variable für die tatsächliche (und evtl. für die reservierte) Größe, aber macht das heutzutage noch irgendwas aus? Meistens hat man ja nicht Arrays mit 2-5 Elementen sondern eher so viele, dass man die paar Metadaten gar nicht mehr merkt.

Und schreiben in eine Datei geht mit vectoren genauso einfach. Alleine schon, weil man ja mit &Vector[0] quasi ein Array hat, ähnlich wie string.c_str(). Und naja, man kann natürich nciht vergessen, dynamsiche Arrays zu löschen, was Memory Leaks vermeidet.

Ein Argument wäre vielleicht, dass man normale Arrays am Stack haben kann, was für kleine Arrays nett sein kann, weil man sich die 'langsame' Speicherallokation spart.

Und wenn einem das bisschen Overhead eines vectors stört, gibt es immer noch boost::array, was nicht langsamer oder größer als ein normales Array ist, aber ein schöneres Interface anbietet.

Zitat von »Jonathan_Klein«

Naja, der Vorteil des Iterator Interfaces ist es, dass man sämtliche Standardalgorithmen aus der STL damit benutzen kann.

Das Anlegen der konkreten Klasse würde ich mehr oder weniger vernachlässigen. Das vergrößert ja ansich nur die ausführbare Datei, und macht das Compilieren etwas langsamer, aber an der Ausführgeschwindigkeit ändert sich ja nichts und auch der Speicherverbrauch pro Objekt dieser konkreten Klasse Objekt bleibt gleich.

Die Einträge in Vektoren können ja auch primitive Typen sein. Und wieso ist es manchmal schlimm, wenn man die Größe ändern kann? Klar, man verbraucht eine Variable für die tatsächliche (und evtl. für die reservierte) Größe, aber macht das heutzutage noch irgendwas aus? Meistens hat man ja nicht Arrays mit 2-5 Elementen sondern eher so viele, dass man die paar Metadaten gar nicht mehr merkt.

Und schreiben in eine Datei geht mit vectoren genauso einfach. Alleine schon, weil man ja mit &Vector[0] quasi ein Array hat, ähnlich wie string.c_str(). Und naja, man kann natürich nciht vergessen, dynamsiche Arrays zu löschen, was Memory Leaks vermeidet.

Ein Argument wäre vielleicht, dass man normale Arrays am Stack haben kann, was für kleine Arrays nett sein kann, weil man sich die 'langsame' Speicherallokation spart.

Und wenn einem das bisschen Overhead eines vectors stört, gibt es immer noch boost::array, was nicht langsamer oder größer als ein normales Array ist, aber ein schöneres Interface anbietet.

Ja doch ich weiss ich nutze sie doch selber extensiv aber ich fand die aussage dass normale arrays zu verwenden schon gute gründe braucht fand ich etwas exzessiv. wenn jemand sagt warum zeiger wenn auch referenz geh ich voll mit - mehr wollte ich nicht kund tun.