Warum ist std::valarray so spartanisch? [Wünsche für den nächsten C++-Standard]
-
std::valarray ist nicht als Container gedacht und findet sich deshalb auch im Standard nicht in der "Containers library", sondern in der "Numerics library" - es geht hier gedanklich nicht darum, etwas aufzubewahren, sondern um Algebra. std::valarray versteht sich dementsprechend mehr als ein Vektor im mathematischen Sinne, und an einen Vektorraum pappt man in der Regel nicht einfach neue Dimensionen ran.
Das Ganze versucht so eine Art rudimentäres BLAS bzw. für derartige Systeme nützliche, effiziente Basiswerkzeuge zur Verfügung zu stellen. Es macht in Verbindung mit den anderen (weniger bekannten) Klassen bzw. Klassenvorlagen aus dieser Bibliothek Sinn - slice, mask_array etc. In die Reihe von deque, vector und list passt valarray dagegen nicht.
-
@seldon: Was spricht dagegen, std::valarray sowohl als Container als auch als mathematisches Objekt nutzen zu können? Ich denke nicht, dass Iteratoren Performanceprobleme mit sich bringen würden.
-
wxSkip schrieb:
@seldon: Was spricht dagegen, std::valarray sowohl als Container als auch als mathematisches Objekt nutzen zu können?
Es sind zwei völlig unterschiedliche Konzepte. Es bringt nichts, mit dem Trecker auf Rallye fahren zu wollen, genausowenig bringts was, mit dem Rallye-Auto einen pflug zu ziehen. Selbst wenn Rallye-Streifen einen Trecker nicht schwächer machen würden und eine Kupplung für landwirtschaftliche Geräte den Rallye-wagen nicht merklich verlangsamen würden.
-
pumuckl schrieb:
wxSkip schrieb:
@seldon: Was spricht dagegen, std::valarray sowohl als Container als auch als mathematisches Objekt nutzen zu können?
Es sind zwei völlig unterschiedliche Konzepte. Es bringt nichts, mit dem Trecker auf Rallye fahren zu wollen, genausowenig bringts was, mit dem Rallye-Auto einen pflug zu ziehen. Selbst wenn Rallye-Streifen einen Trecker nicht schwächer machen würden und eine Kupplung für landwirtschaftliche Geräte den Rallye-wagen nicht merklich verlangsamen würden.
Bloß dass hier das Rallye-Auto den Pflug schneller und mit weniger Sprit ziehen könnte als der Trecker (und teurer wäre es auch nicht).
Wobei man das das meiste bekommt man wahrscheinlich auch mit std::vector und <algorithm> erreichen kann.
-
Nun ja, zunächst mal, dass das bestehende valarray-Interface sich mit den Anforderungen an einen Container beißt - valarray::resize setzt alle Elemente auf den angegebenen Wert, nicht nur die neuen, und die Konstruktoren passen nicht zusammen, um zwei Beispiele zu nennen.
Was speziell Iteratoren betrifft, so ist problematisch, dass der Standard es valarray und Konsorten explizit erlaubt, mit Proxy-Objekten um sich zu werfen - jede Funktion, die ein std::valarray<T> zurückgibt, darf stattdessen ein Proxy-Objekt zurückgeben, das aber die selben const-Methoden zur Verfügung stellen muss. Wir befinden uns jetzt also im neuen Standard und schreiben beispielsweise
std::valarray<int> a; ... auto b = -a;...und haben ein Proxy-Objekt gecacht, das aus Performancegründen die neuen Werte noch nicht ausgerechnet hat. Jetzt muss es uns möglich sein,
std::valarray<int>::const_iterator iter = b.begin();zu schreiben, und wir haben ein Problem: Der Iterator bleibt gültig, bis sich an b etwas entscheidendes ändert. Kommen wir also wie folgt daher:
std::valarray<int> a(10); auto b = -a; auto iter = b.begin(); a[0] = 2; // wie bleibt iter hier gültig?Übrigens ist
std::count(&array[0], &array[0]+array.size(), true)fehlerhafter Code; valarray garantiert nicht, dass die Werte hintereinander im Speicher aufbewahrt werden. Dafür ist etwas wie subarray unproblematisch:
std::valarray<int> a; std::valarray<int> b = a[std::splice(2, 5, 1)]; // 5 Werte ab Element 2 im Abstand von jeweils 1
-
pumuckl schrieb:
Es bringt nichts, mit dem Trecker auf Rallye fahren zu wollen, genausowenig bringts was, mit dem Rallye-Auto einen pflug zu ziehen. Selbst wenn Rallye-Streifen einen Trecker nicht schwächer machen würden und eine Kupplung für landwirtschaftliche Geräte den Rallye-wagen nicht merklich verlangsamen würden.
Der Vergleich ist mir noch etwas zu nah beieinander. Ich würde es wie folgt ausdrücken: Valarray als Container zu benutzen ist etwa so, als benutze man einen Taschenrechner als Notizblock.
-
seldon schrieb:
als benutze man einen Taschenrechner als Notizblock.
Oder das Telefon als Fotoapparat.
Moment. Ach Mist...
-
Nur, dass etwas gemacht wurde, bedeutet nicht, dass es eine gute Idee war. :p
-
seldon schrieb:
Nur, dass etwas gemacht wurde, bedeutet nicht, dass es eine gute Idee war. :p
Und dass man etwas machen könnte, muss nicht heißen, dass man es auch gleich so machen sollte
Sprich, wenn du mit deinem Telefon (valarray) fotografieren (iterieren) möchtest (oder umgekehrt), es im Laden (Standard) aber nur "normale" Telefone und Fotoapparate gibt, dann musst du eben den Lötkolben nehmen und deinem Telefon ne Linse oder dem Fotoapparat ne Sprechmuschel einbauen
Oder jemand war wie du der Meinung, es müsse sowas doch unbedingt geben und verkauft sowas schon fertig (Bibliothek im Netz)
-
seldon schrieb:
std::valarray<int> a(10); auto b = -a; auto iter = b.begin(); a[0] = 2; // wie bleibt iter hier gültig?Was meinst du mit "gültig"? Speichert a einen Zeiger auf den Proxy und sobald a geändert wird, übernimmt der Proxy die Daten von a, damit die Daten im Proxy nicht verändert werden, aber der Iterator zeigt noch auf a? Wenn ja, warum macht man mit Iterator und Proxy nicht das gleiche wie mit Proxy und valarray?
Ansonsten verstehe ich das Problem.
pumuckl schrieb:
Sprich, wenn du mit deinem Telefon (valarray) fotografieren (iterieren) möchtest (oder umgekehrt), es im Laden (Standard) aber nur "normale" Telefone und Fotoapparate gibt, dann musst du eben den Lötkolben nehmen und deinem Telefon ne Linse oder dem Fotoapparat ne Sprechmuschel einbauen
Oder jemand war wie du der Meinung, es müsse sowas doch unbedingt geben und verkauft sowas schon fertig (Bibliothek im Netz)Dann reiche ich einen Antrag beim Laden ein, weil ich es nicht eilig habe.