spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

1. Da fehlt eine Klammer
2. sprintf akzeptiert nur CStrings, ein .c_str () sollte das Problem also lösen.

3. blabla ist ein Typ und keine konkrete Instanz. Daher ist *der Typname* auch nicht zulässig.

Außerdem würde ich empfehlen, in C++ mit stringstreams zu arbeiten, sprintf() ist eine Altlast aus C...

Ja. Ich muss aber auch zugeben, dass ich es manchmal noch benutze. Ist halt wesentlich kürzer %04d zu schreiben als den Stream umständlich zu manipulieren. Boost Format soll auch cool sein.

Eigentlich müsste man da oben aber halt vor dem Aufruf wohl auf die Größe des Outputbuffers achten etc. und dann isses auf einmal nicht mehr wirklich einfacher. Man sollte zumindest snprintf() verwenden statt printf(). Aber auch das hat keine Typsicherheit und gerade bei der Mischung von C++ string Objekten und C Output Funktionen stellt es die Leute regelmäßig auf, weil sie was durcheinanderbringen, den Compiler mit wilden Casts zum schweigen bringen und mit dem falschen Compiler am falschen OS dann auf einmal bei allen schnellen Testläufen die Small String Optimization greift, gerade an der richtigen Stelle eine 0 im Stackframe eingebaut ist und es dann aussieht, als würde alles funktionieren, das Ding in Wahrheit aber eine tickende Zeitbombe ist...

Man munkelt, dass die alten C Funktionen auch etwas schneller sind ("Effektiv C++", glaube ich), aber sie sind halt auch einfach schlechter (s.o.). Und dass es in einem Programmteil, der Strings verarbeitet auf Geschwindigkeit ankommt (jedenfalls in diesem Maße) ist ziemlich ungewöhnlich...

Es kommt darauf an, was du machst.
Wenn jemand eine große Textdatei verarbeitet, sei es XML oder irgendein anderes Format, dann sind langsame Stringfunktionen nicht schön. Das Argument, dass es bei bei dir bisher ziemlich ungewöhnlich war, rechtfertigt nicht eine gezogene Handbremse, wenn sie zu vermeiden ist. Außerdem widerspricht es der Designphilosophie von C++.

Meiner Meinung nach sind die IO Streams der schlimmste Teil der Standardbibliothek. Geschwindigkeit ist ein Grund, aber es gibt noch viele andere. Zum Beispiel sind sie immer State Behaftet. Das im Hintergrund liegende Klassendesign ist sehr kompliziert. Dateisystem und Stringverarbeitung wurde auf sehr bizarre Weise vermischt.

C-Buffer mit C-Funktionen sind auch nicht gerade schön zu verwenden und sehr fehleranfällig. Ein anständiger Compiler oder die statische Analyse von Visual Studio findet zwar die typischen Fehler, aber Perfekt ist es natürlich nicht. Es gibt sicher bessere Alternativen zu beiden. Ich kenne nicht die Funktionen von Boost, aber wenn ich mir nicht schon einmal selbst einmal die notwendigen String-Funktionen geschrieben hätte, würde ich mir zum Beispiel das anschauen. Mich stört besonders, dass die C++ IO Streams immernoch häufig gerade zu missionarisch als viel besser dargestellt werden.

Und jetzt... back to Topic?