Speicher aufgebraucht
-
Bei std::array ist die Größe eine Compilezeit-Konstante.
-
Danke euch allen, ja, das hab ich natürlich verpennt zu includen.
Ich nehme an, am besten schreib ich sämtliche arrays nach dem Schema um, sodass ich keine weiteren Speicherprobleme bekomme..!?
Zu dem zweidimensionalen komme ich erst später, aber ich denke das könnte ich dann vollends alleine hinkriegen.
Danke nochmals
-
useheap schrieb:
Danke euch allen, ja, das hab ich natürlich verpennt zu includen.
Ich nehme an, am besten schreib ich sämtliche arrays nach dem Schema um, sodass ich keine weiteren Speicherprobleme bekomme..!?
Zu dem zweidimensionalen komme ich erst später, aber ich denke das könnte ich dann vollends alleine hinkriegen.
Danke nochmalsDer typische Stolperstein bei vector in vector, den vermutlich jeder macht, ist zu vergessen, dass man den inneren vectoren erst einmal Elemente zuweisen muss, bevor diese Elemente benutzen kann. Klingt zwar ganz einleuchtend, aber irgendwie kommt die Frage hier dauernd.
-
314159265358979 schrieb:
Bei std::array ist die Größe eine Compilezeit-Konstante.
Stimmt, hab das grad durcheinandergeworfen.
-
314159265358979 schrieb:
Warum gibts eigentlich noch keinen std::vector mit fixer Größe (aber dennoch Heap-Allokation)?
Ein vector hat genau dann eine fixe Größe, wenn du sie nicht veränderst.
-
Und du hast nicht verstanden was ich überhaupt will. Danke trotzdem für den sinnlosen Beitrag.
-
Es ist aber relativ einfach, eine Vectorgröße als Compilezeitkonstante zu haben:
const size_t bar_size = 5; vector<foo> bar(bar_size);Dafür eine eigene Klasse in die Standardbibliothek aufnehmen ist doch echt nur Bloat.
-
Und dafür habe ich den Overhead eines size_type im Vector zum speichern der Kapazität (oder eben einen Zeiger, je nach Implementierung), außerdem auf Vorrat zusätzlich angelegte Elemente.
-
314159265358979 schrieb:
Und dafür habe ich den Overhead eines size_type im Vector zum speichern der Kapazität (oder eben einen Zeiger, je nach Implementierung)
Ist das dein Ernst? Nenne mir ein praxisrelevantes Beispiel, wo du derart viele kleine Vektoren mit fixer Größe hast, dass dies eine Rolle spielen würde.
314159265358979 schrieb:
außerdem auf Vorrat zusätzlich angelegte Elemente.
Nein. Keine mir bekannte Implementation der Standardbibliothek reserviert mehr als die angegebene Anzahl bei Verwendung dieses Konstruktors.
-
Athar schrieb:
314159265358979 schrieb:
Und dafür habe ich den Overhead eines size_type im Vector zum speichern der Kapazität (oder eben einen Zeiger, je nach Implementierung)
Ist das dein Ernst? Nenne mir ein praxisrelevantes Beispiel, wo du derart viele kleine Vektoren mit fixer Größe hast, dass dies eine Rolle spielen würde.
Sie sind ja nicht einmal klein, sonst würde er ja ein fixes Array(-klasse) nehmen.
Also, Pi, wenn du wirklich mal einen Fall haben solltest, wo das relevant ist, dann ist das eine Sache von einer Stunde das sauber hin zuschreiben, aber extra eine weitere Klasse in den Standard, das ist einfach zu unnötig.
-
Die STL sollte mal von Policy based class Design Gebrauch machen :S
-
314159265358979 schrieb:
Die STL sollte mal von Policy based class Design Gebrauch machen :S
Wenn meine Zeitmaschine erst einmal läuft, ist das zweite was ich damit tue, dem jungen Herrn Stepanov das Buch "Modern C++ Design" zu schicken. Und auf den Rand des Buches krickel ich noch was von Ranges.
-
Super, dass du das für uns übernimmst.
Nein, mal ehrlich: Ich finde die STL sollte neu designt werden. Das heißt nicht, dass man die alte aufgeben sollte, viel mehr sollte man eine neue, zusätzliche Library entwickeln.
-
Wozu? Was ist denn so schlecht daran? Policy-based Design macht alles unnötig kompliziert.
Ein fixed-size Vektor ist mir auch bisher noch nicht abgegangen. Und wenn man wirklich sowas braucht, dann schreibt man es in ein paar Minuten selbst (muss ja nicht alles unterstützen was der originale Vektor auch kann).Mir gehen da ganz andere Sachen ab. Einiges wurde mit dem neuen Standard nachgeholt (Threads, Regexen etc.), anderes fehlt immer noch (XML, Netzwerk, GUI, ...).
-
Mit Policies kriegt man z.B. thread-safe container, observable container, bound-checking einfach durch ändern der policy. Das wäre total sexy. Ranges, wie von SeppJ schon erwähnt, wären auch super.
-
Mir ist schon klar was man damit machen kann, und was nicht. Ich halte nur nicht alles machbare auch für sinnvoll. Und schon gar nicht für sinnvoller als andere Dinge, die wie schon gesagt immer noch fehlen.
Was thread-safe Container angeht: das kann man mit Policies nicht sinnvoll machen. Dazu muss Client-Code angepasst werden. z.B. kann man dann nichtmehr "if (!v.empty()) v.pop_back();" sagen. Weil das halt nicht thread-safe ist, egal was der Vektor macht. Genauso alle Funktionen die mit Iteratoren rummachen gehören weg etc.
Im Endeffekt läuft es auf ein komplett anderes Container-Interface raus, und damit halte ich es für nichtmehr sinnvoll so zu tun, als ob es noch die gleiche Klasse wäre, bloss halt mit ner anderen Policy.
-
Deshalb sagte ich ja: Bestehende Klassen im Standard lassen, neue Klassen hinzufügen. Das lässt sich bestimmt irgendwie sinnvoll lösen.
Edit: Achso, du meinst es bestünde ein Unterschied im Interface zwischen der Thread-safe und non-thread-safe Variante. Hm. Zumindest sollte es Thread-Safe Varianten im Standard geben. Ob die nun über eine Policy oder eigene Klasse erzeugt werden, ist nicht so wichtig.
-
314159265358979 schrieb:
Zumindest sollte es Thread-Safe Varianten im Standard geben.
Ne. Der umgebenden Code muss threadsafe sein, nicht die Vektoren, die koennen das gar nicht sein. Und PBD ist fast immer bloat. Und Bibliotheken die PBD verwenden sind in etwa so anfaengerfreundlich wie Haskell.
(ausserdem ist das ALlokator Interface bereits eine Policy)
-
Der umgebenden Code muss threadsafe sein, nicht die Vektoren, die koennen das gar nicht sein.
100% Ack.
Zusärtlich, oder als Ausnahme, muss der Zugriff auf statische Member (falls es welche gibt) sicher gemacht werden.
-
nicht die Vektoren, die koennen das gar nicht sein
Natürlich kann man jede Operation synchronisieren.
