Speicher aufgebraucht

hustbaer

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.

314159265358979

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.

otze

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)

theta

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.

Ethon

nicht die Vektoren, die koennen das gar nicht sein

Natürlich kann man jede Operation synchronisieren.

otze

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.

Tachyon

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

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

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)
320kb20 ~ 7 MB - wenn du also 7 MB ram hast, sollte dir das reichen. Ich hoffe mal, dein Rechner schafft so 7MB RAM.

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

Ethon

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