Gibt es eine sprintf ähnliche Funktion für std::string ???

hustbaer

audacia schrieb:

...

+1

pumuckl

audacia schrieb:

pumuckl schrieb:

- gettext/lokalisierung war nirgends gefordert, sind hier also kein Grund, an den für C++ eher unüblichen C-Formatstrings festzuhalten. Wenns gefordert ist fällt mein Beispiel natürlich weg und irgendeine typsichere Format-Bibliothek ist angebracht.

Und was ist mit dem bedauernswerten Menschen, der in zwei Jahren den Auftrag bekommt, deinen Quelltext internationalisierungsfähig zu machen? [...]

Nochmal: Lokalisierung (jetzt oder die Möglichkeit für die Zukunft) war hier nicht gefordert. Wenn es sich um kurzlebige Spielereien handelt , wie >80% der Problemstellungen hier im Forum, ist Streamgeschubse durchaus ok. Der Mensch, der in 2 Jahren meinen Quellcode internationalisieren muss, wird auch kein Stremgeschubse vorfinden. Wenn ich aber weiß, dass mein Code Wegwerfcode ist wie meistens hier im Forum, bei Spielereien, kleinen Lernprogrammen und POCs zu Hause, dann weiß ich, dass es nie zu einer Internationalisierung kommen wird und werde mich auf Bordmittel beschränken, statt zusätzliche Bibliotheken einzubinden oder Zeit für eine schöne, erweiterbare Lösung aufzuwenden, die eh nie erweitert wird.
Wie bereits betont muss man sich natürlich bewusst sein, wie erweiterbar und ausreichend eine Lösung wie das Streamschubsen ist. Man muss sich aber andersrum auch bewusst sein, wann Generalisierung, Erweiterbarkeit etc. keinen Sinn mehr machen.
Deshalb nochmal: Da wo Lokalisierung auf jeden Fall jetzt und in Zukunft ausfällt, braucht man keine lokalisierbaren, mit gettext verwurstbaren Strings.
Ob hier so ein Fall vorliegt muss natürlich der OP selber entscheiden. Aber schön dass wir das Thema angesprochen haben

Nexus

<a href= schrieb:

audacias Homepage">Interessanterweise ist es in durchaus möglich, die oben aufgezählten Probleme systematisch zu vermeiden. Zunächst kann die Speicherverwaltung automatisiert werden, um die Gefahr von Pufferüberläufen bei sprintf() zu beseitigen:
#include <string>
#include <cstdarg>
#pragma hdrstop

std::string str_printf (const char* format, ...)
{
    std::va_list args;
    std::string retval;

    va_start (args, format);

        // Bei der Übergabe von 0 als Puffer ermittelt die Funktion
        // nur die Länge des entstehenden Strings.
    retval.resize (std::vsnprintf (0, 0, format, args));

    std::vsnprintf (&retval[0], retval.size () + 1, format, args);
    va_end (args);

    return retval;
}

Das mag zwar einige Probleme von printf() beheben, aber lange nicht alle (wenig verwunderlich, solange VarArgs verwendet werden). Vor allem ist der Code nicht typsicher. Man kann immer noch Nicht-POD-Objekte übergeben. Du hast auch keine Möglichkeit, die Typen der übergebenen Objekte zur Laufzeit zu erkennen, falsche Formatflags führen nach wie vor zu undefiniertem Verhalten. Der Code ist nicht erweiterbar für eigene Typen.

Auch wenn die C++-Streams bei Weitem nicht ideal sind, zumindest diese Dinge machen sie besser. Zudem davon ermöglichen Streams im Gegensatz zu printf() und str_printf() Typsicherheit zur Kompilierzeit, was manchmal ein nicht zu unterschätzender Vorteil ist. Aber das hast du ja auf deiner Seite selbst erwähnt.

hustbaer

Nexus schrieb:

Man kann immer noch Nicht-POD-Objekte übergeben.

Laut Standard nicht. MSVC mit Extensions erlaubt es allerdings, und GCC gibt nur ne Warning.

ipsec

IMHO ist es laut Standard nur UB, und das auch nur in einem potentiell evaluierten Kontext (in Metaspielereien werden auch oft Ellipsen verwendet, da der Code dort aber zur Laufzeit nicht ausgeführt wird, ist das alles wohldefiniert).

audacia

Nexus schrieb:

Das mag zwar einige Probleme von printf() beheben, aber lange nicht alle (wenig verwunderlich, solange VarArgs verwendet werden). Vor allem ist der Code nicht typsicher. Man kann immer noch Nicht-POD-Objekte übergeben. Du hast auch keine Möglichkeit, die Typen der übergebenen Objekte zur Laufzeit zu erkennen, falsche Formatflags führen nach wie vor zu undefiniertem Verhalten. Der Code ist nicht erweiterbar für eigene Typen.

Wenn du auf meiner Seite noch ein wenig weitergelesen hättest, wäre dir vielleicht aufgefallen, daß Typsicherheit sehr wohl erreichbar ist

Nexus schrieb:

Auch wenn die C++-Streams bei Weitem nicht ideal sind, zumindest diese Dinge machen sie besser. Zudem davon ermöglichen Streams im Gegensatz zu printf() und str_printf() Typsicherheit zur Kompilierzeit, was manchmal ein nicht zu unterschätzender Vorteil ist. Aber das hast du ja auf deiner Seite selbst erwähnt.

Das ist richtig - aber die Verwendung von Formatstrings (und damit die Internationalisierbarkeit) und die Typsicherheit zur Übersetzungszeit schließen einander prinzipbedingt aus. GCC kann zwar Formatstrings zur Übersetzungszeit parsen, aber wenn der eigentliche String von gettext kommt, hilft das auch nichts. Die einzig verbleibende Option ist Typsicherheit zur Laufzeit - und die bekommt man mit 3rd-party-Lösungen wie String::Format() oder boost.format, oder auch für printf() und str_printf(), indem man den Workaround auf meiner Seite anwendet.

hustbaer

ipsec schrieb:

IMHO ist es laut Standard nur UB, und das auch nur in einem potentiell evaluierten Kontext (in Metaspielereien werden auch oft Ellipsen verwendet, da der Code dort aber zur Laufzeit nicht ausgeführt wird, ist das alles wohldefiniert).

Hm. Da wirst du Recht haben

Bitte ein Bit

Dann sag das doch gleich
Ich hätte gedacht, daß gettext ein bekanntes oder zumindest ein googletaugliches Stichwort ist. Aber bitte: mit Lokalisierung alias Internationalisierung meine ich das Bereitstellen von Software in mehreren Anwendersprachen. Gibt man einen Format-String wie den obigen aus, so wird man ihn in mehreren Sprachen bereitstellen wollen. Und spätestens da ist die Stream-Lösung völlig unpraktikabel; ich verweise für ein Beispiel auf den erwähnten Artikel.

Also ich habe keinerlei Probleme mit der Internationalisierung da ich eine eigene Internationalsisierungsfunktionen eingebaut habe. Und da sehe ich keinerlei Unterschied ob ich nun C++ Streams oder Formatstring benutze.

Eisflamme

Aber die Reihenfolge der Wörter! Wie löst Du das, wenn die Satzstellung in ner Sprache anders ist? Wenn Du den Text auf mehreren Sprachen pflegst und über %text1 halt die Positionen der einzufügenden Begriffe wählen kannst, passt das. Bei Streams ist aber die Stellung der variablen Texte fixiert.

Bei Streams müsste man einen Vermittler bauen, der einen gestreamten Text erkennt, weiß, was davon dynamisch ist, und es entsprechend verdreht, wenn die Sprache geändert wird. Äußerst aufwendig. Es sei denn, man hängt halt wieder einen String rein, der nochmal analysiert und umgeschmissen wird, aber dann ist das ja keine wirkliche Stream-Lösung.

Hm... Oder man baut einen ganz neuen Stream, bei dem die Reihenfolge der Elemente von vornerein geändert wird. Beispielsweise hätten wir eine Logik, dass:

("Text1" "Variable" "Text2") auf Deutsch in der Reihenfolge 123 stehen, auf Englisch in der Reihenfolge 231.

international_stream™ << "Die Variable " << var << " ist undefiniert.";
std::cout << international_stream™;

Intern hat international_stream jetzt einen Speicher. Der erkennt, dass "Die Variable " zu dem oben angegeben Tripel gehören. Jetzt muss das Ding nur noch den Unterschied zwischen der Variable und dem Text erkennen. Das kann man über Typangaben lösen... Falls nicht, bräuchte man Manipulatoren:

international_stream™ << text1 << "Die Variable" << var1 << var << text2 << " ist undefiniert.";

oder man gibt ein paar Pattern:

international_stream™ << text_var_text << "Die Variable " << var1 << " ist undefiniert.";

Und dann haut der Stream das alles um, wenn er um die Ausgabe an cout gebeten wird. Blöd ist aber dennoch die Fragmentierung. Vll. gibt es auf irgend einer Sprache nicht links und rechts nen Text? Schlimmer: Vll. gibt es in der Zielsprache drei Fragmente. Letztlich ist man mit den Streams nicht so dynamisch.

Aber die Typsicherheit lässt sich doch sicher auch mit Format-Strings lösen, richtig?

Bitte ein Bit

Ach verflucht! Hast Recht.

Bei Formatstring macht man es einfach:

sprintf(Message, "Person %s nicht erwünscht!", Name);
sprintf(Message, "Person %s is a fucking terrorist!", Name);

Bei Streams müsste man einen Vermittler bauen, der einen gestreamten Text erkennt, weiß, was davon dynamisch ist, und es entsprechend verdreht, wenn die Sprache geändert wird. Äußerst aufwendig. Es sei denn, man hängt halt wieder einen String rein, der nochmal analysiert und umgeschmissen wird, aber dann ist das ja keine wirkliche Stream-Lösung.

Genau auch deswegen die Frage. Denn die einfachste Lösung wäre ja ein sprintf für std::string. Aber dank audacia habe ich jetzt auch eine Lösung.

Message = str_printf("Person %s nicht erwünscht!", Name);
Message = str_printf("Person %s is a fucking terrorist!", Name);

*john 0

audacia schrieb:

Wenn du auf meiner Seite noch ein wenig weitergelesen hättest, wäre dir vielleicht aufgefallen, daß Typsicherheit sehr wohl erreichbar ist

Typsicherheit ist mit Ellipsen grundsätzlich niemals erreichbar! Alles andere ist Selbstbetrug.

Die Ursache liegt darin, daß bei Ellipsen eine variable Anzahl an Argumenten übergeben werden kann, und man durch den Compiler bzw. Linker keinerlei Chance hat, dies jemals sicher zu prüfen. Die ganzen C Format Funktionen können vom Compiler nur dann auf Übereinstimmung geprüft werden, wenn die Formatstrings als Konstanten im Aufruf vorliegen. Ist das nicht der Fall wird selbst diese Einfachprüfung ausgehebelt. Irgend welche Templatespielereien ändern an diesem grundsätzlichen Problem rein gar nichts. Wenn man die Prüfung gar zur Laufzeit verschiebt, hat man das Problem, daß man schon undefined behavior hat, wenn die Zahl der Argumente nicht mit der Anzahl an Formatstringeinträgen übereinstimmt, und somit die Prüfung bereits sinnlos geworden ist.

Was den Themenkomplex Übersetzungen von Software betrifft. Es funktioniert nur mit Einschränkungen einfach die Texte zu übersetzen, die Satzstellung und die Regeln für die Typographie sind in den Sprachen unterschiedlich. Am besten ist in so einem Fall ein polymorphes Verhalten der Ausgabefunktion, so daß man die Ausgabe auch wirklich an alle Erfordernisse der jeweiligen Sprache anpassen kann.

hustbaer

~john schrieb:

audacia schrieb:

Wenn du auf meiner Seite noch ein wenig weitergelesen hättest, wäre dir vielleicht aufgefallen, daß Typsicherheit sehr wohl erreichbar ist

Typsicherheit ist mit Ellipsen grundsätzlich niemals erreichbar! Alles andere ist Selbstbetrug.

Deswegen verwendet audacia ja auch Templates. Wenn du seinen den Artikel gelesen hättest, wüsstest du das

Warum kann man eigentlich nicht einfach

#include <cstdio>

einbinden und dann einfach mit sprintf() 'höchstpersönlich' arbeiten?
Was spricht denn da dagegen, dass man einfach eine schon längst
vorhandene Standard-Funktion (wie z.B. sprintf()) aufruft ?
Genau dazu ist ja so eine Funktion eigentlich da, damit man sie nicht
ständig neu erfinden muss, wenn man sie mal benötigt !!
Oder seh ich da was falsch ?

HighLigerBiMBam

ExperteOhneWerte schrieb:

Warum kann man eigentlich nicht einfach
#include <cstdio>
einbinden und dann einfach mit sprintf() 'höchstpersönlich' arbeiten?
Was spricht denn da dagegen, dass man einfach eine schon längst
vorhandene Standard-Funktion (wie z.B. sprintf()) aufruft ?
Genau dazu ist ja so eine Funktion eigentlich da, damit man sie nicht
ständig neu erfinden muss, wenn man sie mal benötigt !!
Oder seh ich da was falsch ?

Ich weiß auch nicht was dagegen spricht, aber vielleicht sind wir ja nur dumm.

std::string a("test lol");
printf("%s", a.c_str());

Ein temporärer String wird so oder so mit den Streamklassen auch entstehen. Weshalb ich die Ganzen Antworten nicht nachvollziehen will.

hustbaer

@ExperteOhneWerte:
Zeig mal wie du sprintf() verwenden willst, um das Ergebnis in einen std::string zu bekommen (was die ursprüngliche Frage des OP war).
Dann zeig ich dir, was an der Lösung schlecht ist.

----

audacia hat ja bereits eine ausreichend einfache und für viele akzeptabel sichere Version gepostet (str_printf).

hustbaer

@HighLigerBiMBam:
Er will sprintf (man beachte das S) mit std::string verwenden, nicht einen std::string mit printf ausgeben.
D.h. er möchte das Ergebnis in einem std::string haben.

HighLigerBiMBam

hustbaer schrieb:

@HighLigerBiMBam:
Er will sprintf (man beachte das S) mit std::string verwenden, nicht einen std::string mit printf ausgeben.
D.h. er möchte das Ergebnis in einem std::string haben.

Ok da passe ich (es ist Freitag bin zu müde) und finde es sinnlos printf ist viel einfacher :p

hustbaer

Was heisst printf ist viel einfacher?
Wie willst du mit dem resultierenden String mit printf irgendwas machen, ausser ihn auf stdout auszugeben?

Weisst du, es gibt nämlich Fälle wo man das braucht.

Und wenn man das braucht, dann ist " printf ist viel einfacher" ist eine ziemlich sinnlose Aussage. :p

HighLigerBiMBam

hustbaer schrieb:

Was heisst printf ist viel einfacher?
Wie willst du mit dem resultierenden String mit printf irgendwas machen, ausser ihn auf stdout auszugeben?

Weisst du, es gibt nämlich Fälle wo man das braucht.

Und wenn man das braucht, dann ist " printf ist viel einfacher" ist eine ziemlich sinnlose Aussage. :p

Hehe da magst du recht haben

Nexus

Klar kann man nicht beides haben – Typsicherheit zur Kompilierzeit und Formatflags. Man kann aber sehr wohl Typsicherheit zur Laufzeit und Formatflags haben. Aber eben nicht mit der Ellipse.

Und wenn man mit Variadic Templates was bastelt, kommt das boost::format schon sehr nahe, auch wenn dort die etwas konventionellere Operatorüberladung angewendet wird.