Funktionsüberladung nach Rückgabetyp?

Warum unterstützen nicht mehr statisch typisierte Mainstream-Sprachen das Überladen von Funktionen / Methoden nach Rückgabetyp? Mir fällt nichts ein. Es scheint nicht weniger nützlich oder vernünftig zu sein, als die Überladung nach Parametertyp zu unterstützen. Wie kommt es, dass es so viel weniger beliebt ist?

Im Gegensatz zu dem, was andere sagen, Überlastung durch Rückgabetyp ist möglich und wird von einigen modernen Sprachen gemacht. Der übliche Einwand ist, dass in Code wie

int func();
string func();
int main() { func(); }

Sie können nicht sagen, welche func()aufgerufen wird. Dies kann auf verschiedene Arten gelöst werden:

1. Haben Sie eine vorhersehbare Methode, um zu bestimmen, welche Funktion in einer solchen Situation aufgerufen wird.
2. Immer wenn eine solche Situation auftritt, handelt es sich um einen Fehler bei der Kompilierung. Haben Sie jedoch eine Syntax, die es dem Programmierer ermöglicht, zu unterscheiden, z int main() { (string)func(); }.
3. Keine Nebenwirkungen haben. Wenn Sie keine Nebenwirkungen haben und niemals den Rückgabewert einer Funktion verwenden, kann der Compiler vermeiden, die Funktion überhaupt aufzurufen.

Zwei der Sprachen, in denen ich regelmäßig ( ab ) Überladung nach Rückgabetyp verwende: Perl und Haskell . Lassen Sie mich beschreiben, was sie tun.

In Perl gibt es einen grundlegenden Unterschied zwischen skalaren und Liste Kontext (und anderen, aber wir werden es zwei vorgeben ist). Jede in Perl integrierte Funktion kann je nach Kontext unterschiedliche Funktionen ausführen . Beispielsweise joinerzwingt der Operator den Listenkontext (für das zu verbindende Objekt), während der scalarOperator den skalaren Kontext erzwingt. Vergleichen Sie also:

print join " ", localtime(); # printed "58 11 2 14 0 109 3 13 0" for me right now
print scalar localtime(); # printed "Wed Jan 14 02:12:44 2009" for me right now.

Jeder Operator in Perl führt etwas im skalaren Kontext und etwas im Listenkontext aus, und sie können, wie dargestellt, unterschiedlich sein. (Dies gilt nicht nur für zufällige Operatoren wie localtime. Wenn Sie ein Array @aim Listenkontext verwenden, wird das Array zurückgegeben, während im skalaren Kontext die Anzahl der Elemente zurückgegeben wird. So werden beispielsweise print @adie Elemente ausgedruckt, während print 0+@adie Größe gedruckt wird. ) Darüber hinaus kann jeder Operator einen Kontext erzwingen , z. B. Addition +erzwingt skalaren Kontext. Jeder Eintrag in man perlfuncdokumentiert dies. Hier ist zum Beispiel ein Teil des Eintrags für glob EXPR:

Gibt im Listenkontext eine (möglicherweise leere) Liste von Dateinamenerweiterungen für den Wert von zurück, EXPRwie dies die Standard-Unix-Shell /bin/cshtun würde. Im skalaren Kontext durchläuft glob solche Dateinamenerweiterungen und gibt undef zurück, wenn die Liste erschöpft ist.

Wie ist nun die Beziehung zwischen Liste und skalarem Kontext? Nun, man perlfuncsagt

Beachten Sie die folgende wichtige Regel: Es gibt keine Regel, die das Verhalten eines Ausdrucks im Listenkontext mit seinem Verhalten im skalaren Kontext in Beziehung setzt oder umgekehrt. Es könnte zwei völlig verschiedene Dinge tun. Jeder Operator und jede Funktion entscheidet, welche Art von Wert im skalaren Kontext am besten zurückgegeben werden soll. Einige Operatoren geben die Länge der Liste zurück, die im Listenkontext zurückgegeben worden wäre. Einige Operatoren geben den ersten Wert in der Liste zurück. Einige Operatoren geben den letzten Wert in der Liste zurück. Einige Bediener geben eine Anzahl erfolgreicher Vorgänge zurück. Im Allgemeinen tun sie, was Sie wollen, es sei denn, Sie wollen Konsistenz.

Es ist also nicht einfach, eine einzige Funktion zu haben, und am Ende führen Sie eine einfache Konvertierung durch. Tatsächlich habe ich das localtimeBeispiel aus diesem Grund gewählt.

Es sind nicht nur die integrierten Funktionen, die dieses Verhalten aufweisen. Jeder Benutzer kann eine solche Funktion mit definieren wantarray, mit der Sie zwischen Listen-, Skalar- und Leerkontext unterscheiden können. So können Sie beispielsweise entscheiden, nichts zu tun, wenn Sie im ungültigen Kontext aufgerufen werden.

Jetzt können Sie sich beschweren, dass dies keine echte Überladung durch den Rückgabewert ist, da Sie nur eine Funktion haben, der der Kontext mitgeteilt wird, in dem sie aufgerufen wird, und dann auf diese Informationen reagiert. Dies ist jedoch eindeutig gleichwertig (und analog dazu, dass Perl die übliche Überladung nicht buchstäblich zulässt, sondern eine Funktion nur ihre Argumente untersuchen kann). Darüber hinaus wird die zu Beginn dieser Antwort erwähnte zweideutige Situation gut gelöst. Perl beschwert sich nicht darüber, dass es nicht weiß, welche Methode es aufrufen soll. es nennt es einfach. Alles, was es tun muss, ist herauszufinden, in welchem ​​Kontext die Funktion aufgerufen wurde, was immer möglich ist:

sub func {
    if( not defined wantarray ) {
        print "void\n";
    } elsif( wantarray ) {
        print "list\n";
    } else {
        print "scalar\n";
    }
}

func(); # prints "void"
() = func(); # prints "list"
0+func(); # prints "scalar"

(Hinweis: Ich kann manchmal Perl-Operator sagen, wenn ich Funktion meine. Dies ist für diese Diskussion nicht entscheidend.)

Haskell verfolgt den anderen Ansatz, nämlich keine Nebenwirkungen zu haben. Es hat auch ein starkes Typsystem, so dass Sie Code wie folgt schreiben können:

main = do n <- readLn
          print (sqrt n) -- note that this is aligned below the n, if you care to run this

Dieser Code liest eine Gleitkommazahl aus der Standardeingabe und druckt ihre Quadratwurzel. Aber was ist daran überraschend? Nun, die Art von readLnist readLn :: Read a => IO a. Dies bedeutet, dass jeder Typ, der sein kann Read(formal jeder Typ, der eine Instanz der ReadTypklasse ist), readLnihn lesen kann. Woher wusste Haskell, dass ich eine Gleitkommazahl lesen wollte? Nun, die Art von sqrtist sqrt :: Floating a => a -> a, was im Wesentlichen bedeutet, dass sqrtnur Gleitkommazahlen als Eingaben akzeptiert werden können, und so folgerte Haskell, was ich wollte.

Was passiert, wenn Haskell nicht ableiten kann, was ich will? Nun, es gibt ein paar Möglichkeiten. Wenn ich den Rückgabewert überhaupt nicht verwende, ruft Haskell die Funktion einfach gar nicht erst auf. Wenn ich jedoch den Rückgabewert verwende, beschwert sich Haskell, dass der Typ nicht abgeleitet werden kann:

main = do n <- readLn
          print n
-- this program results in a compile-time error "Unresolved top-level overloading"

Ich kann die Mehrdeutigkeit beheben, indem ich den gewünschten Typ spezifiziere:

main = do n <- readLn
          print (n::Int)
-- this compiles (and does what I want)

Wie auch immer, diese ganze Diskussion bedeutet, dass eine Überladung durch den Rückgabewert möglich ist und durchgeführt wird, was einen Teil Ihrer Frage beantwortet.

Der andere Teil Ihrer Frage ist, warum mehr Sprachen dies nicht tun. Ich werde andere das beantworten lassen. Ein paar Anmerkungen: Der Hauptgrund ist wahrscheinlich, dass die Verwechslungsgefahr hier wirklich größer ist als bei der Überladung nach Argumenttyp. Sie können auch Rationales aus einzelnen Sprachen betrachten:

Ada : "Es scheint, dass die einfachste Überlastungsauflösungsregel darin besteht, alles - alle Informationen aus einem möglichst breiten Kontext - zu verwenden, um die überladene Referenz aufzulösen. Diese Regel mag einfach sein, ist aber nicht hilfreich. Sie erfordert den menschlichen Leser Wir glauben, dass eine bessere Regel eine ist, die die Aufgabe, die ein menschlicher Leser oder ein Compiler ausführen muss, explizit macht, und die diese Aufgabe macht, um beliebig große Textstücke zu scannen und willkürlich komplexe Schlussfolgerungen zu ziehen (wie (g) oben) so natürlich wie möglich für den menschlichen Leser. "

C ++ (Unterabschnitt 7.4.1 von Bjarne Stroustrups "The C ++ Programming Language"): "Rückgabetypen werden bei der Überlastungsauflösung nicht berücksichtigt. Der Grund besteht darin, die Auflösung für einen einzelnen Operator oder Funktionsaufruf kontextunabhängig zu halten. Beachten Sie:

float sqrt(float);
double sqrt(double);

void f(double da, float fla)
{
    float fl = sqrt(da);     // call sqrt(double)
    double d = sqrt(da); // call sqrt(double)
    fl = sqrt(fla);            // call sqrt(float)
    d = sqrt(fla);             // call sqrt(float)
}

Wenn der Rückgabetyp berücksichtigt würde, wäre es nicht mehr möglich, einen Aufruf von sqrt()isoliert zu betrachten und festzustellen, welche Funktion aufgerufen wurde. "(Beachten Sie zum Vergleich, dass es in Haskell keine impliziten Konvertierungen gibt.)

Java ( Java Language Specification 9.4.1 ): "Eine der geerbten Methoden muss für jede andere geerbte Methode durch einen Rückgabetyp ersetzt werden können. Andernfalls tritt ein Fehler bei der Kompilierung auf." (Ja, ich weiß, dass dies keine Begründung gibt. Ich bin sicher, dass die Begründung von Gosling in "der Java-Programmiersprache" gegeben wird. Vielleicht hat jemand eine Kopie? Ich wette, es ist im Wesentlichen das "Prinzip der geringsten Überraschung". ) Eine lustige Tatsache über Java: Die JVM ermöglicht das Überladen durch den Rückgabewert! Dies wird beispielsweise in Scala verwendet und kann auch direkt über Java aufgerufen werden, indem mit Interna herumgespielt wird.

PS. Abschließend ist es tatsächlich möglich, mit einem Trick den Rückgabewert in C ++ zu überladen. Zeuge:

struct func {
    operator string() { return "1";}
    operator int() { return 2; }
};

int main( ) {
    int x    = func(); // calls int version
    string y = func(); // calls string version
    double d = func(); // calls int version
    cout << func() << endl; // calls int version
    func(); // calls neither
}

Wenn Funktionen durch den Rückgabetyp überladen wurden und Sie diese beiden Überladungen hatten

int func();
string func();

Der Compiler kann auf keinen Fall herausfinden, welche dieser beiden Funktionen er aufrufen soll, wenn er einen solchen Aufruf sieht

void main() 
{
    func();
}

Aus diesem Grund verbieten Sprachdesigner häufig das Überladen von Rückgabewerten.

Einige Sprachen (wie MSIL), aber sie erlauben durch Rückgabetyp zu überlasten. Natürlich sind auch sie mit der oben genannten Schwierigkeit konfrontiert, aber es gibt Problemumgehungen, für die Sie ihre Dokumentation konsultieren müssen.

Wie würden Sie in einer solchen Sprache Folgendes lösen:

f(g(x))

wenn fhatte Überlastungen void f(int)und void f(string)und ghatte Überlastungen int g(int)und string g(int)? Sie würden eine Art Disambiguator brauchen.

Ich denke, die Situationen, in denen Sie dies benötigen könnten, wären besser zu bedienen, wenn Sie einen neuen Namen für die Funktion wählen.

So stehlen Sie eine C ++ - spezifische Antwort aus einer anderen sehr ähnlichen Frage (Dupe?):

Funktionsrückgabetypen spielen bei der Überlastungsauflösung keine Rolle, nur weil Stroustrup (ich nehme an, dass andere C ++ - Architekten Eingaben gemacht haben) wollte, dass die Überlastungsauflösung "kontextunabhängig" ist. Siehe 7.4.1 - "Überladen und Rückgabetyp" aus der "C ++ - Programmiersprache, dritte Ausgabe".

Der Grund besteht darin, die Auflösung für einen einzelnen Operator oder Funktionsaufruf kontextunabhängig zu halten.

Sie wollten, dass es nur darauf basiert, wie die Überladung aufgerufen wurde - nicht darauf, wie das Ergebnis verwendet wurde (wenn es überhaupt verwendet wurde). In der Tat werden viele Funktionen aufgerufen, ohne das Ergebnis zu verwenden, oder das Ergebnis würde als Teil eines größeren Ausdrucks verwendet. Ein Faktor, von dem ich sicher bin, dass er ins Spiel kam, als sie entschieden, dass wenn der Rückgabetyp Teil der Auflösung wäre, es viele Aufrufe überladener Funktionen geben würde, die mit komplexen Regeln aufgelöst werden müssten oder den Compiler auslösen müssten Ein Fehler, dass der Aufruf nicht eindeutig war.

Und, Gott weiß, die C ++ - Überlastungsauflösung ist derzeit komplex genug ...

In haskell ist dies möglich, obwohl es keine Funktionsüberladung gibt. Haskell verwendet Typklassen. In einem Programm konnte man sehen:

class Example a where
    example :: Integer -> a

instance Example Integer where  -- example is now implemented for Integer
    example :: Integer -> Integer
    example i = i * 10

Funktionsüberladung selbst ist nicht so beliebt. Die meisten Sprachen, die ich damit gesehen habe, sind C ++, vielleicht Java und / oder C #. In allen dynamischen Sprachen ist es eine Abkürzung für:

define example:i
  ↑i type route:
    Integer = [↑i & 0xff]
    String = [↑i upper]


def example(i):
    if isinstance(i, int):
        return i & 0xff
    elif isinstance(i, str):
        return i.upper()

Deshalb macht es nicht viel Sinn. Die meisten Menschen sind nicht daran interessiert, ob die Sprache Ihnen dabei helfen kann, eine einzelne Zeile zu löschen, wo immer Sie sie verwenden.

Pattern Matching ähnelt in gewisser Weise der Funktionsüberladung, und ich denke, manchmal funktioniert es ähnlich. Dies ist jedoch nicht üblich, da es nur für wenige Programme nützlich und in den meisten Sprachen schwierig zu implementieren ist.

Sie sehen, es gibt unendlich viele andere, besser zu implementierende Funktionen, die in die Sprache implementiert werden können, darunter:

• Dynamische Eingabe
• Interne Unterstützung für Listen, Wörterbücher und Unicode-Zeichenfolgen
• Optimierungen (JIT, Typinferenzierung, Kompilierung)
• Integrierte Bereitstellungstools
• Bibliotheksunterstützung
• Community-Unterstützung und Treffpunkte
• Reichhaltige Standardbibliotheken
• Gute Syntax
• Lesen Sie die eval-Druckschleife
• Unterstützung für reflektierende Programmierung

Gute Antworten! Insbesondere die Antwort von A.Rex ist sehr detailliert und lehrreich. Er weist darauf hin, C ++ nicht vom Benutzer bereitgestellte Typumwandlung Betreiber berücksichtigt bei der Kompilierung lhs = func(); (wo func wirklich der Name einer Struktur ist) . Meine Problemumgehung ist etwas anders - nicht besser, nur anders (obwohl sie auf derselben Grundidee basiert).

Während ich schreiben wollte ...

template <typename T> inline T func() { abort(); return T(); }

template <> inline int func()
{ <<special code for int>> }

template <> inline double func()
{ <<special code for double>> }

.. etc, then ..

int x = func(); // ambiguous!
int x = func<int>(); // *also* ambiguous!?  you're just being difficult, g++!

Am Ende hatte ich eine Lösung, die eine parametrisierte Struktur verwendet (mit T = dem Rückgabetyp):

template <typename T>
struct func
{
    operator T()
    { abort(); return T(); } 
};

// explicit specializations for supported types
// (any code that includes this header can add more!)

template <> inline
func<int>::operator int()
{ <<special code for int>> }

template <> inline
func<double>::operator double()
{ <<special code for double>> }

.. etc, then ..

int x = func<int>(); // this is OK!
double d = func<double>(); // also OK :)

Ein Vorteil dieser Lösung besteht darin, dass jeder Code, der diese Vorlagendefinitionen enthält, mehr Spezialisierungen für mehr Typen hinzufügen kann. Sie können bei Bedarf auch Teilspezialisierungen der Struktur vornehmen. Wenn Sie beispielsweise eine spezielle Behandlung für Zeigertypen wünschen:

template <typename T>
struct func<T*>
{
    operator T*()
    { <<special handling for T*>> } 
};

Negativ kann man int x = func();mit meiner Lösung nicht schreiben . Du musst schreiben int x = func<int>();. Sie müssen explizit angeben, um welchen Rückgabetyp es sich handelt, anstatt den Compiler zu bitten, ihn anhand der Typkonvertierungsoperatoren zu ermitteln. Ich würde sagen, dass "meine" Lösung und die von A.Rex beide zu einer paretooptimalen Front gehören , um dieses C ++ - Dilemma anzugehen :)

Wenn Sie Methoden mit unterschiedlichen Rückgabetypen überladen möchten, fügen Sie einfach einen Dummy-Parameter mit dem Standardwert hinzu , um die Ausführung der Überladung zu ermöglichen. Vergessen Sie jedoch nicht, dass der Parametertyp unterschiedlich sein sollte, damit die Überladungslogik als Nächstes funktioniert.

type    
    myclass = class
    public
      function Funct1(dummy: string = EmptyStr): String; overload;
      function Funct1(dummy: Integer = -1): Integer; overload;
    end;

benutze es so

procedure tester;
var yourobject : myclass;
  iValue: integer;
  sValue: string;
begin
  yourobject:= myclass.create;
  iValue:= yourobject.Funct1(); //this will call the func with integer result
  sValue:= yourobject.Funct1(); //this will call the func with string result
end;

Wie bereits gezeigt, führen mehrdeutige Aufrufe einer Funktion, die sich nur durch den Rückgabetyp unterscheidet, zu Mehrdeutigkeiten. Mehrdeutigkeit führt zu fehlerhaftem Code. Fehlerhafter Code muss vermieden werden.

Die Komplexität, die durch den Versuch der Mehrdeutigkeit verursacht wird, zeigt, dass dies kein guter Hack ist. Abgesehen von einer intellektuellen Übung - warum nicht Verfahren mit Referenzparametern verwenden?

procedure(reference string){};
procedure(reference int){};
string blah;
procedure(blah)

Diese Überladungsfunktion ist nicht schwer zu verwalten, wenn Sie sie etwas anders betrachten. Folgendes berücksichtigen,

public Integer | String f(int choice){
if(choice==1){
return new string();
}else{
return new Integer();
}}

Wenn eine Sprache eine Überladung zurückgeben würde, würde dies eine Überladung der Parameter ermöglichen, jedoch keine Duplikationen. Dies würde das Problem lösen von:

main (){
f(x)
}

weil es nur ein f (int choice) zur Auswahl gibt.

In .NET verwenden wir manchmal einen Parameter, um die gewünschte Ausgabe eines generischen Ergebnisses anzugeben, und führen dann eine Konvertierung durch, um das zu erhalten, was wir erwarten.

C #

public enum FooReturnType{
        IntType,
        StringType,
        WeaType
    }

    class Wea { 
        public override string ToString()
        {
            return "Wea class";
        }
    }

    public static object Foo(FooReturnType type){
        object result = null;
        if (type == FooReturnType.IntType) 
        {
            /*Int related actions*/
            result = 1;
        }
        else if (type == FooReturnType.StringType)
        {
            /*String related actions*/
            result = "Some important text";
        }
        else if (type == FooReturnType.WeaType)
        {
            /*Wea related actions*/
            result = new Wea();
        }
        return result;
    }

    static void Main(string[] args)
    {
        Console.WriteLine("Expecting Int from Foo: " + Foo(FooReturnType.IntType));
        Console.WriteLine("Expecting String from Foo: " + Foo(FooReturnType.StringType));
        Console.WriteLine("Expecting Wea from Foo: " + Foo(FooReturnType.WeaType));
        Console.Read();
    }

Vielleicht könnte auch dieses Beispiel helfen:

C ++

    #include <iostream>

enum class FooReturnType{ //Only C++11
    IntType,
    StringType,
    WeaType
}_FooReturnType;

class Wea{
public:
    const char* ToString(){
        return "Wea class";
    }
};

void* Foo(FooReturnType type){
    void* result = 0;
    if (type == FooReturnType::IntType) //Only C++11
    {
        /*Int related actions*/
        result = (void*)1;
    }
    else if (type == FooReturnType::StringType) //Only C++11
    {
        /*String related actions*/
        result = (void*)"Some important text";
    }
    else if (type == FooReturnType::WeaType) //Only C++11
    {
        /*Wea related actions*/
        result = (void*)new Wea();
    }
    return result;
}

int main(int argc, char* argv[])
{
    int intReturn = (int)Foo(FooReturnType::IntType);
    const char* stringReturn = (const char*)Foo(FooReturnType::StringType);
    Wea *someWea = static_cast<Wea*>(Foo(FooReturnType::WeaType));
    std::cout << "Expecting Int from Foo: " << intReturn << std::endl;
    std::cout << "Expecting String from Foo: " << stringReturn << std::endl;
    std::cout << "Expecting Wea from Foo: " << someWea->ToString() << std::endl;
    delete someWea; // Don't leak oil!
    return 0;
}

Für die Aufzeichnung erlaubt Octave unterschiedliche Ergebnisse, je nachdem, ob das Rückgabeelement skalar oder Array ist.

x = min ([1, 3, 0, 2, 0])
   ⇒  x = 0

[x, ix] = min ([1, 3, 0, 2, 0])
   ⇒  x = 0
      ix = 3 (item index)

Vgl. Auch Singular Value Decomposition .

Dieser ist für C ++ etwas anders; Ich weiß nicht, ob es als direkte Überladung durch den Rückgabetyp angesehen werden würde. Es ist eher eine Vorlagenspezialisierung, die sich wie folgt verhält.

util.h

#ifndef UTIL_H
#define UTIL_H

#include <string>
#include <sstream>
#include <algorithm>

class util {
public: 
    static int      convertToInt( const std::string& str );
    static unsigned convertToUnsigned( const std::string& str );
    static float    convertToFloat( const std::string& str );
    static double   convertToDouble( const std::string& str );

private:
    util();
    util( const util& c );
    util& operator=( const util& c );

    template<typename T>
    static bool stringToValue( const std::string& str, T* pVal, unsigned numValues );

    template<typename T>
    static T getValue( const std::string& str, std::size_t& remainder );
};

#include "util.inl"

#endif UTIL_H

util.inl

template<typename T>
static bool util::stringToValue( const std::string& str, T* pValue, unsigned numValues ) {
    int numCommas = std::count(str.begin(), str.end(), ',');
    if (numCommas != numValues - 1) {
        return false;
    }

    std::size_t remainder;
    pValue[0] = getValue<T>(str, remainder);

    if (numValues == 1) {
        if (str.size() != remainder) {
            return false;
        }
    }
    else {
        std::size_t offset = remainder;
        if (str.at(offset) != ',') {
            return false;
        }

        unsigned lastIdx = numValues - 1;
        for (unsigned u = 1; u < numValues; ++u) {
            pValue[u] = getValue<T>(str.substr(++offset), remainder);
            offset += remainder;
            if ((u < lastIdx && str.at(offset) != ',') ||
                (u == lastIdx && offset != str.size()))
            {
                return false;
            }
        }
    }
    return true;    
}

util.cpp

#include "util.h"

template<>
int util::getValue( const std::string& str, std::size_t& remainder ) {
    return std::stoi( str, &remainder );
} 

template<>
unsigned util::getValue( const std::string& str, std::size_t& remainder ) {
    return std::stoul( str, &remainder );
}

template<>
float util::getValue( const std::string& str, std::size_t& remainder ) {
    return std::stof( str, &remainder );
}     

template<>   
double util::getValue( const std::string& str, std::size_t& remainder ) {
    return std::stod( str, &remainder );
}

int util::convertToInt( const std::string& str ) {
    int i = 0;
    if ( !stringToValue( str, &i, 1 ) ) {
        std::ostringstream strStream;
        strStream << __FUNCTION__ << " Bad conversion of [" << str << "] to int";
        throw strStream.str();
    }
    return i;
}

unsigned util::convertToUnsigned( const std::string& str ) {
    unsigned u = 0;
    if ( !stringToValue( str, &u, 1 ) ) {
        std::ostringstream strStream;
        strStream << __FUNCTION__ << " Bad conversion of [" << str << "] to unsigned";
        throw strStream.str();
    }
    return u;
}     

float util::convertToFloat(const std::string& str) {
    float f = 0;
    if (!stringToValue(str, &f, 1)) {
        std::ostringstream strStream;
        strStream << __FUNCTION__ << " Bad conversion of [" << str << "] to float";
        throw strStream.str();
    }
    return f;
}

double util::convertToDouble(const std::string& str) {
    float d = 0;
    if (!stringToValue(str, &d, 1)) {
        std::ostringstream strStream;
        strStream << __FUNCTION__ << " Bad conversion of [" << str << "] to double";
        throw strStream.str();
    }
    return d;
}

In diesem Beispiel wird die Auflösung von Funktionsüberladungen nach Rückgabetyp nicht genau verwendet. Diese C ++ - Nichtobjektklasse verwendet jedoch eine Vorlagenspezialisierung, um die Auflösung von Funktionsüberlastungen nach Rückgabetyp mit einer privaten statischen Methode zu simulieren.

Jede der convertToTypeFunktionen ruft die Funktionsvorlage auf. stringToValue()Wenn Sie sich die Implementierungsdetails oder den Algorithmus dieser Funktionsvorlage ansehen, ruft sie auf getValue<T>( param, param )und gibt einen Typ zurück Tund speichert ihn in einem T*, der stringToValue()als einer seiner Parameter an die Funktionsvorlage übergeben wird .

Anders als so etwas; C ++ verfügt nicht wirklich über einen Mechanismus, mit dem die Auflösung von Funktionen nach Rückgabetyp überladen werden kann. Möglicherweise gibt es andere Konstrukte oder Mechanismen, von denen ich nicht weiß, dass sie die Auflösung nach Rückgabetyp simulieren könnten.

Ich denke, dies ist eine Lücke in der modernen C ++ - Definition… warum?

int func();
double func();

// example 1. → defined
int i = func();

// example 2. → defined
double d = func();

// example 3. → NOT defined. error
void main() 
{
    func();
}

Warum kann ein C ++ - Compiler in Beispiel "3" keinen Fehler auslösen und den Code in Beispiel "1 + 2" akzeptieren?

Die meisten statischen Sprachen unterstützen jetzt auch Generika, die Ihr Problem lösen würden. Wie bereits erwähnt, gibt es ohne Parameterunterschiede keine Möglichkeit zu wissen, welche aufgerufen werden sollen. Wenn Sie dies tun möchten, verwenden Sie einfach Generika und nennen Sie es einen Tag.