MSVC std::to_string broken?
-
Wenn man die richtigen Suchbegriffe eingibt, findet man die Antwort auf magische Weise von selbst.
http://stackoverflow.com/questions/10664699/stdto-string-more-than-instance-of-overloaded-function-matches-the-argument
Warum ein so großer Hersteller trotzdem solchen Mist baut, ist mir schleierhaft.
-
Kellerautomat schrieb:
Ich bastel gerade an einem UI Framework und habe feststellen müssen, dass MSVC's std::to_string offenbar komplett broken ist.
Mir scheint eher, dass dein Deutsch komplett broken ist zusammen mit den Fähigkeiten, minimale Codebeispiele zu bringen und zu googlen.
Kellerautomat schrieb:
Warum ein so großer Hersteller trotzdem solchen Mist baut, ist mir schleierhaft.
Vielleicht solltest du deinen eigenen Link lesen:
Had all of these overloads been present, obviously you wouldn't have this problem. Of course, VC++ 2010 wasn't based on the actual C++11 standard, which didn't exist yet at the time of its release, but rather on N3000, which did not call for these additional overloads.
-
Michael E. schrieb:
Mir scheint eher, dass dein Deutsch komplett broken ist zusammen mit den Fähigkeiten, minimale Codebeispiele zu bringen und zu googlen.
Warum denn der raue Ton? Hast du den Post über deinem überhaupt gelesen? Mal abgesehen davon, mein Codebeispiel ist so ziemlich das minimalste, was geht.
Michael E. schrieb:
Vielleicht solltest du deinen eigenen Link lesen:
Had all of these overloads been present, obviously you wouldn't have this problem. Of course, VC++ 2010 wasn't based on the actual C++11 standard, which didn't exist yet at the time of its release, but rather on N3000, which did not call for these additional overloads.
Hab ich gelesen, trotzdem sollte diese Probleme gerade ein STL-Entwickler erkennen können. Das ist doch sowas von offensichtlich, da füg ich automatisch die Overloads ein, gerade weil es eh nur ein Draft ist.
-
Ich muss jetzt nicht explizit "dass es Sinn ergibt und bekannt ist, welcher Bezeichner was bedeutet" dazuschrieben, oder?
-
Kellerautomat schrieb:
Warum denn der raue Ton?
Entschuldige, das war in der Summe tatsächlich zu unfreundlich von mir.
Hast du den Post über deinem überhaupt gelesen?
Ja, da hast du ergooglet, was du bereits vor dem Starten des Threads problemlos hättest finden können.
Mal abgesehen davon, mein Codebeispiel ist so ziemlich das minimalste, was geht.
Mal schauen:
struct my_window : libui::window { virtual void on_resize(libui::window_resize_event& e) override { set_title('(' + std::to_string((libui::u64)e.to().width) + ',' + std::to_string((libui::u64)e.to().height) + ')'); } };Die struct-Definition samt Ableitung ist überflüssig, die Funktionsdefinition ist überflüssig. Bleibt noch die Zeile
set_title('(' + std::to_string((libui::u64)e.to().width) + ',' + std::to_string((libui::u64)e.to().height) + ')');Der Aufruf von set_title ist überflüssig, der doppelte Aufruf ist überflüssig, das Argument ist unnötig kompliziert. Ich muss erst überlegen, was libui::u64 ist (ist es tatsächlich ein unsigned int der Größe 64 Bit?). Ich muss überlegen, was width ist. Es reicht also auch
unsigned short width = 42; std::to_string(width);Das Ganze kann man jetzt noch in ne main packen und es ist sogar kompilierbar.
Hab ich gelesen, trotzdem sollte diese Probleme gerade ein STL-Entwickler erkennen können. Das ist doch sowas von offensichtlich, da füg ich automatisch die Overloads ein, gerade weil es eh nur ein Draft ist.
Es wird irgendeinen Grund gegeben haben, warum diese Überladungen es nicht in den Draft geschafft haben. Denn wenn die Autoren nicht überlegt hätten, hätten sie einfach alle möglichen Überladungen hinzugefügt. Deshalb sollten Entwickler Dinge, die absichtlich weggelassen wurden, nicht eigenmächtig hinzufügen, ohne einen wichtigen Grund zu haben.
-
Michael E. schrieb:
Es wird irgendeinen Grund gegeben haben, warum diese Überladungen es nicht in den Draft geschafft haben. Denn wenn die Autoren nicht überlegt hätten, hätten sie einfach alle möglichen Überladungen hinzugefügt. Deshalb sollten Entwickler Dinge, die absichtlich weggelassen wurden, nicht eigenmächtig hinzufügen, ohne einen wichtigen Grund zu haben.
Offenbar reine Faulheit, denn nun sind die Overloads im Standard.
-
Kellerautomat schrieb:
Michael E. schrieb:
Es wird irgendeinen Grund gegeben haben, warum diese Überladungen es nicht in den Draft geschafft haben. Denn wenn die Autoren nicht überlegt hätten, hätten sie einfach alle möglichen Überladungen hinzugefügt. Deshalb sollten Entwickler Dinge, die absichtlich weggelassen wurden, nicht eigenmächtig hinzufügen, ohne einen wichtigen Grund zu haben.
Offenbar reine Faulheit, denn nun sind die Overloads im Standard.
Du mutmaßt dir an, die Arbeit des Standardgremiums auf diese Weise zu würdigen. Ufff..., abgesehen sind Sie im C++11 Standard, dessen standardkonformen Kompiler du in den nächsten Jahren nicht von Microsoft bekommen wirst. ;O
-
Ich verstehe es nicht: Es wird also angeprangert, dass ein C++11 Feature nicht von einem C++03 Compiler im Sinne von C++11 unterstuetzt wird. Wenn du C++11 willst, dann nimm doch VS 2012 RC!
-
knivil fixed schrieb:
Ich verstehe es nicht: Es wird also angeprangert, dass ein C++11 Feature nicht von einem C++03 Compiler im Sinne von C++11 unterstuetzt wird. Wenn du C++11 willst, dann nimm doch GCC/Clang!
Fixed.
-
Ethon_ schrieb:
knivil fixed schrieb:
Ich verstehe es nicht: Es wird also angeprangert, dass ein C++11 Feature nicht von einem C++03 Compiler im Sinne von C++11 unterstuetzt wird. Wenn du C++11 willst, dann nimm doch GCC/Clang!
Fixed.
Auf Win?
-
Ich benutzte VC 2012 und habe keine Probleme mit std::to_string.