Wieso kann man in C++ keine Strings mit Ints verknüpfen?
-
Badestrand schrieb:
void foo( std::stringstream& s ); std::stringstream a("Hallo"), b("Welt"); foo( a.str() + b.str() );Das Argument von foo muss noch const sein[/quote]
wieso sollte es das müssen?
-
falsch schrieb:
Badestrand schrieb:
void foo( std::stringstream& s );Das Argument von foo muss noch const sein
wieso sollte es das müssen?
Weil du sonst eine non-const-Referenz auf ein temporäres Objekt hättest, temporäre Objekte sind aber quasi nur zum Lesen und nicht zum Schreiben da..

void foo1( const int& a ); void foo2( int& a ); void kraks() { foo1( 10 ); // Geht foo2( 10 ); // Geht nicht }
-
Nexus schrieb:
...Gehört in Java ein String nicht zu den Grunddatentypen, ...
Eben: Igittibäh !!
Spätestens, weil das mit "myInt" oder "myString" schon nicht mehr geht und auch nicht "gehbar gemacht" werden kann.
Gruß,
Simon2.
-
also bei mir geht beides
(visual c++)
-
falsch schrieb:
also bei mir geht beides
(visual c++)Das ist bedenklich.. Welche Version? Und was passiert, wenn du in foo2 einen Wert zuweist?
-
Jetzt bin ich verwirrt:
void foo2( int& a ) { std::cout << a << std::endl; } void foo3( std::string& s) { std::cout << s << std::endl; } int main() { foo2(10); // geht nicht foo3(std::string("temp")); // geht return 0; }Ich sehe da nicht so den massiven Unterschied...
-
Beim Aufruf von foo3 wird ein temporäres std::string-Objekt vor dem Aufruf erzeugt; näheres kann dir jetzt auch nur noch camper oder irgendwer anderes Standard-vertrautes sagen..
-
Aber dann binde ich ja trotzdem ein temporäres Objekt an eine non-const referenz!
-
Ersteres ist illegal weil 10 vom Typ const int ist, letzteres ist AFAIK „nur“ undefiniertes Verhalten.
-
falsch schrieb:
Aber dann binde ich ja trotzdem ein temporäres Objekt an eine non-const referenz!
Es ist aber immerhin nicht so temporär wie eins, das extra für den Aufruf erstellt wird
Naja, ich weiß nicht, vielleicht weil das string-Objekt explizit erzeugt wird? Wie gesagt, hier bin ich mit meinem Latein am Ende...
-
Beide Funktionsaufrufe sind ill-formed, falls der Compiler das anders sieht, erlaubt das nur Rückschlüsse bezüglich dessen Standardkonformität. Was geht bzw. geht-nicht bedeuten soll, weis ich nicht. "Temporär" kann man nicht steigern :p
-
geht bedeutet, dass es der compiler übersetzt.
geht nicht bedeutet, dass der compiler an dieser zeile stehen bleibt und den fehler bemängelt.dann haben wir also offiziell nicht-standardkonformes verhalten in visual c++ 2005 ausgemacht?
-
Bashar schrieb:
groovemaster schrieb:
Bashar schrieb:
groovemaster schrieb:
'~' ist immerhin auch der Operator für bitweise Negierung.
Nein, das ist der unäre Operator.
Und nachts ist es kälter als draussen.
Ob unär oder nicht ist bezugslos zu meiner Aussage. '~' ist und bleibt ein Operator.Aber du hast schon verstanden, was ich ausdrücken will?
Klar. Nur ging es mir ja um einen separaten Operator, der bisher noch nicht verwendet wird. Ob unär, binär oder ternär spielt dabei keine Rolle. Daher war dein Kommentar etwas unpassend. Oder glaubst du, mir ist nicht bewusst, dass '~' für binäre Verknüpfungen noch nicht verwendet wird?
-
groovemaster schrieb:
Bashar schrieb:
Aber du hast schon verstanden, was ich ausdrücken will?
Klar. Nur ging es mir ja um einen separaten Operator, der bisher noch nicht verwendet wird.
Das stört bei anderen Operatoren (wie * und &) doch auch keinen, also muss die Frage erlaubt sein, warum du diese Analogie ignorierst.
-
falsch schrieb:
Jetzt bin ich verwirrt:
void foo2( int& a ) { std::cout << a << std::endl; } void foo3( std::string& s) { std::cout << s << std::endl; } int main() { foo2(10); // geht nicht foo3(std::string("temp")); // geht return 0; }Ich sehe da nicht so den massiven Unterschied...
FAQ: http://www.c-plusplus.net/forum/viewtopic-var-t-is-39474.html
-
Sorry, habe alle Antworten vorher nicht gesehen!!!
weil beim std::string der += operator für den Typ int nicht implementiert ist.
Das kannst du aber selber machen oder die eine eigene String Klasse schreiben,
die das macht. In anderen Sprachen haben sich eben die Entwickler die Mühe gemacht,für solche Probleme eine Funktion oder eben einen operator zu schreiben.
Man sollte deshalb aber nicht über C++ meckern.
Sorry, habe alle Antworten vorher nicht gesehen!!!
-
falsch schrieb:
geht bedeutet, dass es der compiler übersetzt.
geht nicht bedeutet, dass der compiler an dieser zeile stehen bleibt und den fehler bemängelt.dann haben wir also offiziell nicht-standardkonformes verhalten in visual c++ 2005 ausgemacht?
Schmeißt er wenigstens ne Warnung raus? Kann man ihn vielleicht in einen megakonformen Modus schalten in dem er sowas ablehnt?
-
.filmor schrieb:
Kann man ihn vielleicht in einen megakonformen Modus schalten in dem er sowas ablehnt?
Selbstverständlich gibt es diesen (und ist auch nicht schwer zu finden)- was bedeutet, dass falsch seine Hausaufgaben nicht gemacht hat. Das wiederum war der Grund, warum ich gar nicht erst darauf hingewiesen habe.
-
hgfdsa schrieb:
camper schrieb:
hgfdsa schrieb:
Warum geht das bei stringstream aber nicht bei string?
DrakoXP täuscht sich hier. Eine solche Überladung führt nicht zu Mehrdeutigkeiten, wenn das Argument 0 ist, da habe ich auch nicht aufgepasst.
std::string& operator+(std::string& str, int i) { std::stringstream ss; ss << i; str += ss.str(); return str; } int main(int argc, char** argv) { int i = 0; std::stringstream stream; stream << "NULL = "; stream << i; //geht stream << 0; //geht std::cout<<stream.str(); std::string strNull = "Null = "; strNull += i; //geht strNull += 0; //geht nicht return 0; }Mit Visual Studio 2008 kompiliert das letzte aber nicht
error C2593: 'Operator +=' ist mehrdeutig
Warum?
Warum ist es denn nun genau bei "+=0" Mehrdeutig?
Und vorallem warum geht dann das?strNull = strNull + 0;Hat das irgend nen sinnvollen Grund, oder ist das nur ein komischer Nebeneffekt?
-
hgfdsa schrieb:
Warum ist es denn nun genau bei "+=0" Mehrdeutig?
Weil die beiden Kandidaten
std::string& std::string::operator+=(const char* s); std::string& std::operator+=(char c);eine gleich gute Wahl darstellen (der 3. Kandidat
std::string& std::string::operator+=(const std::string& str);benötigt einen Konvertierungskonstruktor und ist deshalb schlechter). Keiner dieser Kandidaten ist eine Templatefunktion.
Und vorallem warum geht dann das?
strNull = strNull + 0;Mit deiner einem eigenen Operator ist das doch kein Problem? Keiner der Standardüberladungen von operator+ für std::string kommt in Frage, denn dabei handelt es sich ausnahmslos um Templates, keines davon verfügt über eine Spezialisierung die zu den deduzierten Parametertypen passt.