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

[audacia]

pumuckl schrieb:

was spricht gegen

Es ist unübersichtlich, doppelt so lang und macht es unmöglich, den String mit gettext() o.ä. zu lokalisieren?

[wiesonichtschnell]

314159265358979 schrieb:

void print(std::ostream& s, const char* str)
{
        s << str;
}
 
template <typename Head, typename... Tail>
void print(std::ostream& s, const char* str, Head&& head, Tail&&... tail)
{
        while(*str != '%')
                s << *str++;
        s << head;
 
        print(s, ++str, std::forward<Tail>(tail)...);
}
 
template <typename... Args>
std::string print(std::string format, Args&&... args)
{
        std::stringstream ss;
        print(ss, format.c_str(), std::forward<Args>(args)...);
        return ss.str();
}

Sicherlich nicht das schnellste, aber typsicher.

Das meiste passiert doch zur Compiletime oder nicht?

[314159265358979]

Weil ich std::ostringstream verwende
(Übrigens habe ich meinen Post noch 2 mal editiert, einmal const string& und das zweite mal ostringstream.)

[Eisflamme]

audacia schrieb:

pumuckl schrieb:

was spricht gegen

Es ist unübersichtlich, doppelt so lang und macht es unmöglich, den String mit gettext() o.ä. zu lokalisieren?

Wenn Du das unübersichtlich findest, dann muss Dir ganz C++ unübersichtlich erscheinen. Die Lokalisation des Strings halte ich für unnötig, wozu sollte man das brauchen?

Pi*10^wasauchimmer:
Wo liegt der Vorteil ggü. pumuckls Code?

[audacia]

Eisflamme schrieb:

Wenn Du das unübersichtlich findest, dann muss Dir ganz C++ unübersichtlich erscheinen.

So ist es. Aber wieso meinst du das?

Eisflamme schrieb:

Die Lokalisation des Strings halte ich für unnötig, wozu sollte man das brauchen?

Ist jetzt nicht dein Ernst, oder?

[314159265358979]

Der Voteil meines Codes ist die Übersichtlichkeit, sonst gar nichts

[Eisflamme]

Ich find pumuckls Code weit übersichtlicher.

audacia:
In C++ baut man vieles durch solche Streams auf. Das mag Dir unorthodox erscheinen, wenn Du damit nicht vertraut bist, tatsächlich hat es aber viele Vorteile. Letztlich kann man sich sehr gut an die Syntax gewöhnen, was er mir wert ist, wenn ich dafür Streams nutzen darf.

Und ja, es ist mein Ernst. Aber ich muss zugeben, dass ich gar nicht verstehe, was du mit Lokalisation des Strings meinst. Erklärst Du es mir oder kriege ich auf den Post nur eine weitere rhetorische Frage?

[314159265358979]

std::cout << print("% + % = %", 4, 5, 42);

Also ich finde das übersichtlicher als:

std::cout << 3 << " + " << 5 << " = " << 42;

[Eisflamme]

Mir gefällt daran nicht, dass die Reihenfolge der Elemente vertauscht wird. Die 4 erscheint nach dem +, obwohl sie davor kommt. Bei << hat man zwar den ganzen Ausdruck nicht auf einen Blick mit Variablen, dafür sieht man aber bereits alle Elemente, kann von links nach rechts lesen ohne zwischendurch zu springen und hat den Ausdruck nur etwas aufgebläht. Die Alternative ist mir lieber, aber jedem das seine.

[314159265358979]

Möglichkeit #3: http://ideone.com/cMlRb

[Eisflamme]

Man kann operator, überladen?

Das ist cool, aber die Syntax ist jetzt nicht C++-like. Du hast jetzt << durch , ersetzt. So schlimm finde ich << einfach nicht. Es gibt mir das Gefühl von Bewegung und Dynamik und da ich sonst nur faul rumsitze, befriedigt das mein Gewissen. Ist C++ nicht einfach toll? :p

[audacia]

Eisflamme schrieb:

In C++ baut man vieles durch solche Streams auf. Das mag Dir unorthodox erscheinen, wenn Du damit nicht vertraut bist, tatsächlich hat es aber viele Vorteile.

Und ebenso viele Nachteile. Weiß ich selbst. Wenn dich die Frage tatsächlich interessiert, gibts in meiner Signatur einen Link zu einem Artikel.

Eisflamme schrieb:

Und ja, es ist mein Ernst. Aber ich muss zugeben, dass ich gar nicht verstehe, was du mit Lokalisation des Strings meinst.

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.

[Begeistert]

314159265358979 schrieb:

void print(std::ostream& s, const char* str)
{
        s << str;
}
 
template <typename Head, typename... Tail>
void print(std::ostream& s, const char* str, Head&& head, Tail&&... tail)
{
        while(*str != '%')
                s << *str++;
        s << head;
 
        print(s, ++str, std::forward<Tail>(tail)...);
}
 
template <typename... Args>
std::string print(const std::string& format, Args&&... args)
{
        std::ostringstream ss;
        print(ss, format.c_str(), std::forward<Args>(args)...);
        return ss.str();
}

Sicherlich nicht das schnellste, aber typsicher.

Schönes Beispiel für Perfect Forwarding
Auch wenn es natürlich noch keine explizite Formatierung unterstützt ala
printf, aber die kann man ja ergänzen...

[Bitte ein Bit]

Wow, danke für die vielen Tips!

was spricht gegen

std::ostringstream ostr;
ostr << "Koordinaten des Punktes: (" << << setfill('0') << setw(3) << x << ' ' << y << ')';
std:.string S = ostr.str();

Nun ja,

Übersichtlichkeit ist hier so eine Sache. Die sprintf Anweisung ist zwar kompakt aber er ist nicht für jeden lesbar welcher keine Ahnung von Formatstrings hat. Einen etwas unverständlicheren Formatstring habe ich mal bei einem sscanf Befehl benutzt:

%*[^:]: V = %lf

Da ist die Sache mit den Stringstreams besser lesbar aber halt auch länger.

Aber hier sehe ich noch eine kleine Schwierigkeit denn der sprintf Befehl mit seinen Formatstrings ist überaus mächtig. Da müsste ich mich halt mal in Stringstreams einarbeiten.

[Eisflamme]

Achsooo, okay, ich hatte Lokalisation gar nicht in Verbindung mit Streams gebracht und gettext erschien mir ohne das zu prüfen schon nicht googlebar, aber jetzt habe ich das gelesen.

Konkret: Lokalisation geht nicht auf Grund von anderen Satzstellungen in anderen Sprachen, richtig? Sonst wären Streams ja genau so gut.

[pumuckl]

Bitte ein Bit schrieb:

Da müsste ich mich halt mal in Stringstreams einarbeiten.

Wenn du das noch nicht getan hast solltest du das auf jeden Fall mal machen - unabhängig davon ob es für deinen Fall jetzt ausreichend ist oder nicht.

audacia schrieb:

Es ist unübersichtlich, doppelt so lang und macht es unmöglich, den String mit gettext() o.ä. zu lokalisieren?

- Unübersichtlichkeit ist realtiv, wie auch schon andere bemerkt haben. Ob man jetzt die Streamoperatoren und -manipulatoren übersichtlicher findet als einen Formatstring voller Platzhalter, wo die ganzen Ersetzungen erst am Schluss kommen ist wohl Gewöhnungs- und Geschmackssache.
- Doppelt so lang ist fast kein Argument. Wenn mein Code kurz und bündig sein soll nehm ich Perl und veranstalte Regex-Schlachten oder was anderes in der Art. Länge beeinflusst nur die Tipparbeit und die Übersichtlichkeit. Letztere s.o. Code wird einmal geschrieben und N-mal gelesen -> Lesbarkeit und Ausdrucksstärke schlägt Tippfaulheit bei weitem.
- 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.

[audacia]

Eisflamme schrieb:

Konkret: Lokalisation geht nicht auf Grund von anderen Satzstellungen in anderen Sprachen, richtig?

Nö. Das ist nur das KO-Argument. (Außerdem kann man da mit printf() auch ins Schwimmen geraten, weil es zumindest nach dem Standard keine positionsbezogene Referenzierung ermöglicht; da muß man dann entweder eine Erweiterung oder gleich eine 3rd-party-Lösung wie String::Format() oder boost.format verwenden.) Wenn du gettext verwendest, bekommt der Übersetzer einfach eine Liste der Strings, die er in die jeweilige Sprache anpassen muß. Mit Format-Strings etwa so (ich bediene mich einfach mal in der Delphi-Laufzeitbibliothek):

'A class named %s already exists'
'Cannot assign a %s to a %s'
'CheckSynchronize called from thread $%x, which is NOT the main thread'
'Thread Error: %s (%d)'
...

Wenn du die Strings zerlegst und die Einzelteile mit gettext internationalisieren willst, bekommt der Übersetzer das:

'A class named '
' already exists'
'Cannot assign a '
' to a '
'CheckSynchronize called from thread '
', which is NOT the main thread'
'Thread Error: '
' ('
')'
...

Und soweit ich weiß, haushaltet gettext mit der Reihenfolge nach eigenem Gutdünken (z.B., um identische Strings zusammenzulegen), so daß es sehr unwahrscheinlich ist, daß obige Schnipsel in einer sinngebenden Reihenfolge auftauchen.

Kurzum: gettext und Streams geht einfach nicht.

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? Dem wird nichts übrigbleiben, als all dein wunderschön übersichtliches, maximal ausführliches, ideal lesbares Streamgeschubse leider wegwerfen zu müssen.

Formatierung durch Streams sollte man grundsätzlich nicht benutzen, wenn lokalisierungsspezifische Dinge (z.B. Strings in einer bestimmten Sprache) im Spiel sind. Das ist ähnlich töricht, wie wenn du einfach den Speicher nicht freigibst, nur weil dein Programm in seiner gegenwärtigen Inkarnation z.B. nur auf der Kommandozeile aufgerufen wird und dort maximal 1-2s läuft, so daß das System ohnehin aufräumt. Wehe dem, der das hinterher aufräumen muß.

[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.