ich steh grad etwas aufm Schlauch bei diesem eigentlich leichten Code:

std::ostringstream stream;
stream << 100;
const char* resolution = stream.str().c_str();

Laut Debugger ist nach diesen 3 Zeilen resultion == "". Wieso ist resolution nicht == "100"?

std::ostringstream stream; 
stream << 100; 

// str.c_str() liefert schon const char*, aber str muss dafür im Speicher bleiben

// variable für str anlegen:
string str = stream.str();
const char* resolution = str.c_str(); // voila

MfG SideWinder

stream << graphicsSettings.devType;
writeIniString("devtype", stream.str().c_str());
stream.str("");

stream << graphicsSettings.windowed;
writeIniString("windowed", stream.str().c_str());
stream.str("");

// das jetzt noch sehr, sehr oft...

Ich will lediglich lauter integrale Daten als sicher per const char* an ne Funktion übergeben. Geht das irendwie eleganter?

Oh man, dieses string/stream Gefrickel is in C++ echt ätzend.

Find ich auch schlimm Aber dafür schreibt man sich ja Funktionen wie der Dr. schon vorgeschlagen hat ...

template<class T, class S>
T lexical_cast(const S& val)
{
    stringstream sstr("");
    T newval;
    if( !( sstr << val && sstr >> newval ) )
       throw bad_cast();

    return newval;
}

MfG SideWinder

Oh man, dieses string/stream Gefrickel is in C++ echt ätzend.

Wenn Du damit nicht umgehen kannst, dann ist das nicht zwangsweise Gefrickel. Mein Tip: Einfach keinen Zeiger verwenden . Immer std::string statt const char*. Dann gibt es keine Probleme mehr (na ja - es gibt natürlich noch viele Probleme, wie z. B. wie ich reich werde oder so - aber das ist hier off-topic).

this->that schrieb:

Oh man, dieses string/stream Gefrickel is in C++ echt ätzend.

Wenn Du damit nicht umgehen kannst, dann ist das nicht zwangsweise Gefrickel. Mein Tip: Einfach keinen Zeiger verwenden . Immer std::string statt const char*. Dann gibt es keine Probleme mehr (na ja - es gibt natürlich noch viele Probleme, wie z. B. wie ich reich werde oder so - aber das ist hier off-topic).

UTF8...

this->that schrieb:

Oh man, dieses string/stream Gefrickel is in C++ echt ätzend.

Wenn Du damit nicht umgehen kannst, dann ist das nicht zwangsweise Gefrickel. Mein Tip: Einfach keinen Zeiger verwenden . Immer std::string statt const char*. Dann gibt es keine Probleme mehr (na ja - es gibt natürlich noch viele Probleme, wie z. B. wie ich reich werde oder so - aber das ist hier off-topic).

Je ne is klar. In manchen Bereichen is C++ nun mal einfach grausig. Was in andren Sprachen nen Double.Parse() is, muss man in C++ mit Templates oder ekligen Klassen erschlagen. Und wenn du die WinAPI kennen würdest, wüsstest du, dass man um char* einfach nicht herum kommt.

Templates oder ekligen Klassen erschlagen

Aha. Und was meinst du was C++ ist?
Es kann keiner etwas für deine Unfähigkeit. Templates sind etwas sehr schönes, wenn man fähig ist sie richtig zu nutzen.

Und wenn du die WinAPI kennen würdest, wüsstest du, dass man um char* einfach nicht herum kommt.

Kommt davon wenn man C und C++ mischen muss ... WinAPI ist nunmal C.

stream << graphicsSettings.devType;
writeIniString("devtype", stream.str().c_str());
stream.str("");

stream << graphicsSettings.windowed;
writeIniString("windowed", stream.str().c_str());
stream.str("");

Davon abgesehen das da jedesmal nen clear fehlt ... falls der mal nicht in der Lage sein sollte deinen Mist umzuwandeln ... ist das doch normal? Wenn du etwas irgendwo reinsteckst und du dann aber nur noch was anderes drin haben willst, musst du das alte erstmal rauswerfen!? Wo ist dein Problem ...

Ihr seid ja mal extrem lächerlich. Wenn ihr Probleme mit C++ habt, könnt ihr ja mal Kritik abgeben, die aber nicht durch euer mangelhaftes Können hervorgerufen wird.

So und jetzt viel Spaß ...

Wo ist dein Problem ...

Das Problem ist, dass this->that nicht sowas schreiben kann :

int zahl = Convert.ToString(zahl_text);
//bzw.
int zahl = Integer.parseInt(zahl_text);

Stattdessen muss er sich selbst eine Funktion zum Konvertieren schreiben oder auf boost::lexical_cast zurückgreifen.
Das ganze ist natürlich nicht ganz so gemütlich, wie in anderen Sprachen.

Das es kein lexical_cast im std gibt, find ich seltsam und das nervt mich auch öfters. Was gibts da langes zu überlegen, ob man es reinnehmen bzw. wie implementiert sein sollte ?

Warum nahm man nicht sämtliche Mathefunktionen in die cmath auf? Weil man mit den vorhandenen Funktion fast alles andere ohne weiteres machen kann!

... bzw. C++ nicht so wie die manch andere Sprachen aufblähen wollte.

(D)Evil schrieb:

Wenn du noch irgendwas brauchst, legst du dir einen Header MyUntilities an und packst da mal schön nen haufen Funktionne die du immer wieder brauchst rein! Schon bist du fertig.

Gut kann man machen, aber der Erstaufwand bleibt ( wenn wir beim lexical_cast bleiben ) für etwas was _ich_ als "oftgebräuchlisch" ansehen würde. Es gehört zu den primitivsten Sachen.
Eine Mathe-Funktion würd ich als etwas externes ansehen, etwas das keinen festen Bezug zu Sprache hat, die nötigsten reichen deshalb.
Aber sowas wie ein lexical_cast gehört imho zum internen Bestandteil einer Sprache, es schließlich etwas, was die Konvertierung zwischen den Datentypen einer Sprache bereitstellt.

Also meiner Meinung nach _etwas_ was im std sein sollte

@(D)Evil: Brauchst nicht gleich ausfallend werden, nur weil ich die von dir offenbar geliebte Sprache kritisiere. Mit etwas Objektivität wüsstest du, dass C++ in manchen Situation einfach grausig ist. Mir wegen so nem trivialen Scheiß ne eigene Templatefunktion schreiben zu müssen IST grausig.

@hmmmmmmm: Nein leider nicht. Das writeIniString ist nur ne Dummyfunktion für mein Beispiel gewesen. In Wirklichkeit steht da ne WinAPI Funktion, die mehrere char* benötigt.

...Mit etwas Objektivität wüsstest du, dass C++ in manchen Situation einfach grausig ist. Mir wegen so nem trivialen Scheiß ne eigene Templatefunktion schreiben zu müssen IST grausig....

Meine Arbeitskollegin schrieb:

Der Javaprogrammierer erwartet von der Sprache, dass sie die Vereinigungsmenge aller möglichen Spezialfälle umfasst, während der C++-Programmierer nur die Schnittmenge braucht.

Hier haben wir anscheinend ein Beispiel dafür.

Gruß,

Simon2.