Warum wählt der Compiler Bool anstelle von String für implizite Typumwandlung von L ""?

Hat kürzlich eine Überladung einer Methode eingeführt, bei der die Anwendung fehlgeschlagen ist. Schließlich wird die neue Methode dort aufgerufen, wo ich nicht damit gerechnet habe.

Wir hatte

setValue( const std::wstring& name, const std::wstring& value );

std::wstring avalue( func() );
setValue( L"string", avalue );
std::wstring bvalue( func2() ? L"true", L"false" );
setValue( L"bool", bvalue );
setValue( L"empty", L"" );

Es wurde so geändert, dass beim Speichern eines Bool-Werts dieselben Zeichenfolgen verwendet werden (interne Datenspeicherung von Zeichenfolgen).

setValue( const std::wstring& name, const std::wstring& value );
setValue( const std::wstring& name, const bool& value );

std::wstring avalue( func() );
setValue( L"string", avalue );
setValue( L"bool", func2() );
setValue( L"empty", L"" ); << --- this FAILS!?!

Das Problem mit L "" ist, dass es implizit Casting ist und früher froh war, ein std :: wstring zu sein, aber nicht, dass es lieber ein Booler ist. Der MSVC-Compiler beklagt sich nicht oder gibt keine Warnung aus. Daher mache ich mir Sorgen, dass, selbst wenn ich den Wert setValue "korrigiere" (L "leer", L ""); sei

setValue( L"empty", std::wstring() );

jemand anderes kann später kommen und einfach setValue (L "leer", L "") verwenden; und müssen dieses Problem erneut aufspüren.

ir dachten, explizit für die Methode zu verwenden, aber es ist kein gültiges Schlüsselwort für diese Verwendung. Gibt es eine Möglichkeit, den Compiler dazu zu bringen, sich darüber zu beschweren oder das Problem auf andere Weise zu verhindern? Andernfalls überlege ich, den Namen der Methode zu ändern, die einen Bool benötigt, um sicherzustellen, dass keine falschen Vermutungen angestellt werden können.

Antworten auf die Frage(10)

Ihre Antwort auf die Frage