3. Speicher aufgebraucht

Speicher aufgebraucht

  • Mod

    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.

    0
  • 3

    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.

    0
  • A

    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.

    0
  • Mod

    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.

    0
  • 3

    Die STL sollte mal von Policy based class Design Gebrauch machen :S

    0
  • Mod

    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.

    0
  • 3

    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.

    0

  • 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, ...).

    0
  • 3

    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.

    0

  • 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.

    0
  • 3

    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.

    0
  • O

    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)

    0
  • T

    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.

    0
  • E

    nicht die Vektoren, die koennen das gar nicht sein

    Natürlich kann man jede Operation synchronisieren.

    0
  • O

    Ethon schrieb:

    Natürlich kann man jede Operation synchronisieren.

    das wiegt dich aber nur in Sicherheit. Siehe SeppJs Gegenbeispiel:

    if(!v.empty()) 
    v.pop_back();

    empty kann thread safe sein, pop_back auch, aber die Kombination geht nicht.

    Beispiel mit 2 threads:

    v.size() ist 1:
    thread1: if(!v.empty()) ->true
    thread2: if(!v.empty()) ->true
    thread2: v.pop() -> v.size() = 0
    thread1: v.pop() ->oops

    Besser ists da offen zu sagen, dass der vector nicht thread safe ist, dann kann niemand Magie von ihm erwarten.

    0
  • T

    Viel schlimmer ist das bei Iteratoren. begin und end in Kombination sind auch nicht threadsafe.

    0
  • ?

    Hallo nochmal,
    hab das gut hinbekommen mit den komplexen arrays einer Größe von 2000 Elementen.
    Dabei geht um 0.001-Schritte von minus pi bis plus pi.
    Jetzt überlege ich ob ich das ganze noch etwas verfeinere und 0.0001-Schritte gehe. Dadurch erhoffe ich mir bessere / schnellere Ergebnisse. Dazu bräuchte es ja:

    vector<complex<double>> fit1(20000);

    Und davon benutz ich auch mehrere.
    Könnte das was den Speicher angeht Probleme geben?
    Oder gibts da ne maximale Größe...?
    Angenommen ich hab 20 solche arrays, 10 complex double und 10 double...

    0
  • ?

    Das is rein ne Frage wieviel RAM du hast. complex<double> sind 2 mal double = 16 byte. 20k16 byte ~ 320kb (overhead vom vector is da vernachlässigbar)
    320kb    20 ~ 7 MB - wenn du also 7 MB ram hast, sollte dir das reichen. Ich hoffe mal, dein Rechner schafft so 7MB RAM.

    0
  • ?

    Danke, also mein PC hat
    Standard Ram: 512MB (entfernbar)
    Maximum Ram: 4GB
    Denke das war auch eher ironisch gemeint!? Kenn mich da halt mal gar net aus.
    Also gibts auch keine Probleme, wenn das Programm auf beliebigen anderen Rechnern läuft? Deren Arbeitsspeicher reicht in jedem Fall..?

    0
  • E

    7Mb RAM hat wohl jeder PC der letzten 10 Jahre. 🙄
    Und höchstwarscheinlich würde das Betriebssystem da zu swappen anfangen.

    0
Anmelden zum Antworten