On Monday 06 October 2003 17:50, Stefan Hundhammer wrote:
On Monday 06 October 2003 17:43, Sebastian Huber wrote:
Das halte ich für eine sehr gewagte Annahme. Das wird früher oder später kläglich scheitern!
Also so gewagt ist das nicht! Wichtige STL Implementierungen (Hewlett-Packard, ist bei MS Visual Studio 6.0 dabei; GNU + Hewlett-Packard + SGI, bei gcc 3.3) verwenden ein zusammenhaengendes Feld.
Es mag wohl sein, daß die es gerade jetzt genau so tun, aber garantiert wird das nirgendwo - d.h. es ist per Definition ein Implementierungsdetail.
Ja, es ist ein Implementierungsdetail, aber das "gerade jetzt" ist schlichtweg untertrieben. HP hat so um 1994 seine STL Implementierung veroeffentlicht und seitdem wird ein std::vector mit drei Zeigern (start, finish, end_of_storage) implementiert. Einfacher geht es wohl kaum, und gerade deswegen ist es ja wohl hoechst unwahrscheinlich, dass sich hier was aendern wird.
Jede Implementierung kann das anders machen (und schon geht die Portabilität dahin), und bei jeder Version kann das anders sein - ohne jede Vorankündigung (und da kommen die Cores bei Lib-Updates). Sich auf so etwas zu verlassen, ist grob fahrlässig.
Ich kann hier keine grobe Fahrlaessigkeit erkennen und bin wohl kaum der einzige, der sich in diesem Punkt darauf verlaesst.
Ich zumindest bin mir ziemlich sicher, daß der C++ -Standard NIRGENDS irgendwelche derartigen Zusicherungen macht.
Ich kenne den Standard nicht, aber wie Ralf geschrieben hat, scheint die Sache ja nicht so abwegig zu sein.
Wenn die Informatiker in Zukunft nicht etwas voellig Revolutionaeres im Hinblick auf Vektorimplementierungen herausfinden, dann wird sich das auch nicht so schnell aendern.
So wahnsinnig revolutionär muß so etwas gar nicht sein.
Doch, denn die Sparsetechniken sind ja auch schon lange bekannt, man hat sie aber nicht gewaehlt. Der std::vector ist auch nicht fuer duennbesetzte Felder da, wenn jemand so etwas hat, dann wird er wohl einen passenden Spezialcontainer suchen.
Denn warum soll man ein seit Jahren bewaertes Verfahren grundsaetzlich ueber Bord werfen?
Weil es sich einfach nur auf Implementierungsdetails verläßt, die zufälligerweise bei den verwendeten Versionen gerade so sind?
Das ist keine Antwort auf meine obige Frage, die sich auf die Implementierung von std::vector bezieht.
Weil man robusten, zuverlässigen Code haben will? Weil man sich Tretminen und Zeitbomben im Code ersparen will?
Gut, loesen wir es Britisch: We agree do disagree. Ciao Sebastian