Ich bastel gerade an einem UI Framework und habe feststellen müssen, dass MSVC's std::to_string offenbar komplett broken ist.
Folgendes Stück Code:

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) + ')');
	}
};

Sobald ich die expliziten Casts entferne (beides sind u16 Werte), krieg ich diese Fehlermeldungen:

1>------ Build started: Project: libui, Configuration: Debug Win32 ------
1> main.cpp
1>c:\users\fubar\documents\visual studio 2010\projects\libui\libui\main.cpp(14): error C2668: 'std::to_string' : ambiguous call to overloaded function
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\string(688): could be 'std::string std::to_string(long double)'
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\string(680): or 'std::string std::to_string(_ULonglong)'
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\string(672): or 'std::string std::to_string(_Longlong)'
1> while trying to match the argument list '(libui::u16)'
1>c:\users\fubar\documents\visual studio 2010\projects\libui\libui\main.cpp(14): error C2668: 'std::to_string' : ambiguous call to overloaded function
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\string(688): could be 'std::string std::to_string(long double)'
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\string(680): or 'std::string std::to_string(_ULonglong)'
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\string(672): or 'std::string std::to_string(_Longlong)'
1> while trying to match the argument list '(libui::u16)'
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Woran liegt denn das?

Grüße,
Der Kellerautomat

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.

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.

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.

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.

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 GCC/Clang!

Fixed.

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?