STL Implementierung & Kompilator werden gesucht!

[ronny]

das geht auch einfacher

mit:

return string(istreambuf_iterator<char>(input), istreambuf_iterator<char>())

sollte das bereits gegessen sein

[hustbaer]

Zdravko schrieb:

Ich stelle die Frage wieder anders: ich habe eine Datei aus Zeichen, die ich in einem string speichern will.
Jetzt mach ich das so:

/*...*/
string contents_; //our container for the characters
/*...*/
file_reader::file_reader(const string& filename) {
	//opening the file
	ifstream input(filename.c_str());
	//checking if the file exists
	if(!input || !input.is_open())
		throw Error::error("no or bad input filename", __FILE__, __LINE__);
	//copying all the contents into the string
	istreambuf_iterator<char> ii(input), ie;
	copy(ii, ie, back_inserter(contents_));
}

Das Problem ist, dass string keine Methode push_back hat. VS2005 bietet es aber. Das hilft mir nicht, denn ich will fair spielen

Nimm gleich std::vector<char> und nen back_inserter.

A Back Insertion Sequence is a Sequence where it is possible to append an element to the end, or to access the last element, in amortized constant time.

std::string garantiert das AFAIK nicht, und daher ist auch kein push_back vorgesehen. std::vector garantiert das sehr wohl, daher gibts ein push_back.
Eigentlich ganz einfach, oder?

Ahja, wenn du mit "push_back" fertig bist machste natürlich mit std::string(vec.begin(), vec.end()) nen string draus, sollte logisch sein.

Alternativ kannste statt std::copy einfach std::for_each nehmen, und nen eigenen "str_appender" Funktor mitgeben, ein "korrekter" Funktor ist halt viel einfacher zu basteln als ein "korrekter" Iterator.

p.S.: ich würde eben nen std::vector<char> nehmen, eben weil std::string nur unzureichende "complexity specifications" hat. Viele std::string Implementierungen sind auf Speicherverbrauch optimiert, und das verträgt sich halt nicht mit "schnellem push_back/append".

p.p.S.: wenn du wirklich den "am besten standard-konformen" C++ Compiler suchst, dann guck dir mal den Comeau an. Kostet fast nix (50$ glaub ich), und kann als Backend den VC verwenden.

[camper]

Ich bin grad am Grübeln, wie 23.1.1/12 zu verstehen ist:

ISO/IEC 14882 schrieb:

Table 68 lists sequence operations that are provided for some types of sequential containers but not others. An implementation shall provide these operations for all container types shown in the ‘‘container’’ column, and shall implement them so as to take amortized constant time.

Stellt das der Implementation frei, diese Funktionen auch in anderen Containern (der Standardbibliothek), die nicht in der Liste stehen, zu implementieren oder nicht? Die Tabelle selbst ist überschrieben mit "Optional sequence operations" - das optional ist da ein Schlüsselwort für mich. Wenn hier keine Wahl bestünde, wäre doch eine andere Wortwahl angebracht? Zudem hat string ohnehin einige dieser Funktionen (wie op[]), ohne in der Tabelle erwähnt zu werden.

[hustbaer]

Pf. Gute Frage.
Geht aus dem Absatz IMHO nicht eindeutig hervor.

Auf jeden Fall kenne ich die "Regel" (allerdings auch nur vom "hörensagen") dass z.B. "push_back" IMMER in "amortized constant time" laufen "muss", sonst sollte es nicht angeboten werden (nicht unter dem Namen).
Mehr als dieses vage "sollte, müsste, blah" kann ich leider nicht anbieten.

Allerdings bin ich mir 99% sicher dass der Std. für basic_string nicht *vorschreibt* dass man in "amortized constant time" Elemente anfügen kann, von daher verlasse ich mich auch nicht darauf.

[Simon2]

Zdravko schrieb:

Ja, ganz genau. Nach Standard hat string keine Methode push_back. ...

camper schrieb:

...Die Tabelle selbst ist überschrieben mit "Optional sequence operations" - das optional ist da ein Schlüsselwort für mich. Wenn hier keine Wahl bestünde, wäre doch eine andere Wortwahl angebracht? Zudem hat string ohnehin einige dieser Funktionen (wie op[]), ohne in der Tabelle erwähnt zu werden.

Habe selbst mal nachgesucht:

• im Standard ("Corrigendum No. 1") finde ich push_back() aber

21.3.5.2 basic_string::append schrieb:

"...
11 void push_back(charT c)
Effects: Equivalent to append(static_cast<size_type>(1), c) .
...

• www.cppreference.com listet sie
• "Die C++ Standardbibliothek", Kuhlins/Schader listet sie
• "Die C++ Programmiersprache", Stroustrup, 4. Auflage listet sie

Also für mich bedeutet das: Sie ist lt. Standard vorgesehen.

Gruß,

Simon2.

[Artchi]

Dinkumware listet sie auch, und die sind in der LWG (Library Working Group) des C++ Komitee dabei.
http://www.dinkumware.com/manuals/?manual=compleat&page=string2.html#basic_string::push_back

[khalderon]

Naja, dann haben wir kein Problem! std::back_inserter funzt einfach toll unter VC2005.

[lolz]

Simon2 schrieb:

"Die C++ Programmiersprache", Stroustrup, 4. Auflage listet sie

Auf welcher Seite hast du Sie darin gefunden? Als ich Gestern Abend gesucht habe habe ich sie nicht gefunden.

[camper]

Simon2 schrieb:

"Die C++ Programmiersprache", Stroustrup, 4. Auflage listet sie

vierte Auflage?

[Artchi]

Also in der dt. 4. Auflage von Stroustrup kann ich kein string::push_back finden. Wobei ich den Stroustrup nicht gerade für sowas heranziehen würde. Jedenfalls nicht, wenn es um eine 100% Auflistung aller Schnittstellen geht.

Simon2! Kannst du bitte das Kapitel nennen, wo du es gefunden hast?

Stefan Kuhlins und Martins Schraders Buch über die Standardlib führt allerdings auch string::push_back auf.

[camper]

Oh, die Übersetzung der Special Edition wird hierzulande als 4. Auflage gehandelt. Sehr verwirrend...

[Simon2]

lolz schrieb:

Simon2 schrieb:

"Die C++ Programmiersprache", Stroustrup, 4. Auflage listet sie

Auf welcher Seite hast du Sie darin gefunden? Als ich Gestern Abend gesucht habe habe ich sie nicht gefunden.

S. 635, Kapitel 20.3.9 "Strings/asic_string/Einfügen".
Da kommen erst 3 operator+=() und dann push_back();

camper schrieb:

...vierte Auflage?

"Jeeeeeersey ?!"
Ich weiß nicht so recht, was Deine Frage bedeutet.
Im Deckel steht:
"Bjarne Stroustup
Die C++ Programmiersprache
4, aktualisierter und erweiterte Auflage"

und die ISBN lautet 3-8273-1660-X
EDIT sieht, dass Du sie inzwischen gefunden hast.

Artchi schrieb:

...Wobei ich den Stroustrup nicht gerade für sowas heranziehen würde. Jedenfalls nicht, wenn es um eine 100% Auflistung aller Schnittstellen geht....

Ich eigentlich auch nicht, aber nachdem ich sie im Standard erst nicht fand, habe ich mal die Bücher auf meinem Tisch durchforstet und da war der halt auch dabei....

Gruß,

Simon2.

[Artchi]

Simon2! Stimmt, steht da tatsächlich. Würde mal sagen, nach den ganzen Referenzen aus allen möglichen Quellen, gehört push_back dazu.

[lolz]

Tatsächlich, wie konnte ich den bloß übersehen

[hustbaer]

Ich würde trotzdem nen vector nehmen

[Gast++]

Ich kann den Wnnsch, sich nicht an STL- oder sonstigen Inkompatibilitaeten auseinandersetzen zu müssen bestens verstehen.

Aber ich hab noch nie ein grösseres Projekt gesehen, das trotz "portablem" Design einfach so durch einem anderen Compiler lief.

Als "Smoke-Test" kann man den plattform-unabhängigen Teil mal auf der jeweils "anderen" Platform durchkompilieren, also z.B. ein Win32 VC Projekt mit dem Linux g++ und umgekehrt.
Wenn sogar _das_ geht klappt's imho mit anderen Compiler auf der gleichen Platform auch mit vertretbarem Aufwand.
Das ist aber die ganz harte Variante der QS; dazu muss das Projekt natuerlich entsprechende Layer aufweisen.

Im vorliegenden Fall und gerade in Anbetracht der kontroversen Diskussion würde ich von "push_back" Abstand nehmen und "+=" verwenden.

Es ist halt leider so: Wenn man wirklich "portablen" Code haben möchte kommtm man imho an trial-and-error nicht vorbei; am Zeichenbrett lässt sich nicht alles vorausssehen.

Grüsse

*this

[hustbaer]

Gast++ schrieb:

Es ist halt leider so: Wenn man wirklich "portablen" Code haben möchte kommtm man imho an trial-and-error nicht vorbei; am Zeichenbrett lässt sich nicht alles vorausssehen.

ACK
Aber nicht nur wegen dem Zeichenbrett, sondern z.B. auch einfach deswegen weil Implementierungen diverser Libs die es für mehrere Plattformen gibt (und an denen kommt man bei grösseren Projekten kaum vorbei) eben auf den verschiedenen Plattformen - leider - oft unterschiedliches Verhalten zeigen.