Chức năng quá tải theo kiểu trả về?

Tại sao các ngôn ngữ chính được gõ tĩnh hơn hỗ trợ chức năng / phương thức nạp chồng theo kiểu trả về? Tôi không thể nghĩ ra cái nào làm được. Có vẻ như không hữu ích hoặc hợp lý hơn là hỗ trợ quá tải theo loại tham số. Tại sao nó lại ít phổ biến hơn?

Trái với những gì người khác đang nói, quá tải theo kiểu trả về là có thể và được thực hiện bởi một số ngôn ngữ hiện đại. Sự phản đối thông thường là trong mã như

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

bạn không thể biết cái nào func()đang được gọi. Điều này có thể được giải quyết theo một số cách:

1. Có một phương pháp dự đoán để xác định hàm nào được gọi trong tình huống như vậy.
2. Bất cứ khi nào một tình huống như vậy xảy ra, đó là một lỗi thời gian biên dịch. Tuy nhiên, có một cú pháp cho phép lập trình viên định hướng, ví dụ int main() { (string)func(); }.
3. Đừng có tác dụng phụ. Nếu bạn không có tác dụng phụ và bạn không bao giờ sử dụng giá trị trả về của hàm, thì trình biên dịch có thể tránh việc gọi hàm ở vị trí đầu tiên.

Hai trong số các ngôn ngữ tôi thường xuyên ( ab ) sử dụng quá tải theo kiểu trả về: Perl và Haskell . Hãy để tôi mô tả những gì họ làm.

Trong Perl , có một sự phân biệt cơ bản giữa bối cảnh vô hướng và danh sách (và các bối cảnh khác, nhưng chúng ta sẽ giả vờ có hai). Mỗi hàm tích hợp trong Perl có thể làm những việc khác nhau tùy thuộc vào ngữ cảnh mà nó được gọi. Ví dụ, jointoán tử buộc liệt kê bối cảnh (trên vật được nối) trong khi scalartoán tử buộc bối cảnh vô hướng, vì vậy hãy so sánh:

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.

Mỗi toán tử trong Perl làm một cái gì đó trong bối cảnh vô hướng và một cái gì đó trong bối cảnh danh sách, và chúng có thể khác nhau, như được minh họa. (Điều này không chỉ dành cho các toán tử ngẫu nhiên như localtime. Nếu bạn sử dụng một mảng @atrong ngữ cảnh danh sách, nó sẽ trả về mảng, trong khi ở ngữ cảnh vô hướng, nó sẽ trả về số lượng phần tử. Ví dụ, print @ain ra các phần tử, trong khi print 0+@ain kích thước. ) Hơn nữa, mọi toán tử có thể buộc một bối cảnh, ví dụ như bổ sung các +lực vô hướng. Mỗi mục trong man perlfunctài liệu này. Ví dụ, đây là một phần của mục nhập cho glob EXPR:

Trong ngữ cảnh danh sách, trả về một danh sách (có thể trống) các mở rộng tên tệp trên giá trị EXPRnhư shell Unix tiêu chuẩn /bin/cshsẽ làm. Trong bối cảnh vô hướng, global lặp đi lặp lại thông qua các mở rộng tên tệp như vậy, trả về undef khi danh sách đã hết.

Bây giờ, những gì liên quan giữa danh sách và bối cảnh vô hướng? Vâng, man perlfuncnói

Hãy nhớ quy tắc quan trọng sau: Không có quy tắc nào liên quan đến hành vi của một biểu thức trong ngữ cảnh danh sách với hành vi của nó trong ngữ cảnh vô hướng hoặc ngược lại. Nó có thể làm hai việc hoàn toàn khác nhau. Mỗi toán tử và hàm quyết định loại giá trị nào sẽ phù hợp nhất để trả về trong bối cảnh vô hướng. Một số toán tử trả về độ dài của danh sách sẽ được trả về trong ngữ cảnh danh sách. Một số toán tử trả về giá trị đầu tiên trong danh sách. Một số toán tử trả về giá trị cuối cùng trong danh sách. Một số nhà khai thác trả lại một số lượng các hoạt động thành công. Nói chung, họ làm những gì bạn muốn, trừ khi bạn muốn sự nhất quán.

Vì vậy, đó không phải là vấn đề đơn giản khi có một chức năng duy nhất và sau đó bạn thực hiện chuyển đổi đơn giản vào cuối. Trong thực tế, tôi đã chọn localtimeví dụ cho lý do đó.

Nó không chỉ là các phần mềm tích hợp có hành vi này. Bất kỳ người dùng nào cũng có thể định nghĩa một hàm như vậy bằng cách sử dụng wantarray, cho phép bạn phân biệt giữa danh sách, vô hướng và bối cảnh trống. Vì vậy, ví dụ, bạn có thể quyết định không làm gì nếu bạn bị gọi trong bối cảnh trống.

Bây giờ, bạn có thể phàn nàn rằng đây không phải là quá tải thực sự bởi giá trị trả về vì bạn chỉ có một chức năng, được cho biết bối cảnh mà nó được gọi và sau đó hành động theo thông tin đó. Tuy nhiên, điều này rõ ràng tương đương (và tương tự như cách Perl không cho phép quá tải thông thường theo nghĩa đen, nhưng một hàm chỉ có thể kiểm tra các đối số của nó). Hơn nữa, nó giải quyết tốt tình huống mơ hồ được đề cập ở phần đầu của phản ứng này. Perl không phàn nàn rằng nó không biết nên gọi phương thức nào; nó chỉ gọi nó Tất cả những gì nó phải làm là tìm ra bối cảnh mà hàm được gọi trong đó, điều này luôn luôn có thể:

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"

(Lưu ý: Đôi khi tôi có thể nói toán tử Perl khi tôi muốn nói đến chức năng. Điều này không quan trọng đối với cuộc thảo luận này.)

Haskell có cách tiếp cận khác, cụ thể là không có tác dụng phụ. Nó cũng có một hệ thống loại mạnh và vì vậy bạn có thể viết mã như sau:

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

Mã này đọc một số dấu phẩy động từ đầu vào tiêu chuẩn và in căn bậc hai của nó. Nhưng điều gì đáng ngạc nhiên về điều này? Vâng, loại readLnlà readLn :: Read a => IO a. Điều này có nghĩa là đối với bất kỳ loại nào có thể Read(chính thức, mọi loại là một thể hiện của Readlớp loại), readLnđều có thể đọc nó. Làm thế nào mà Haskell biết rằng tôi muốn đọc một số dấu phẩy động? Vâng, kiểu sqrtlà sqrt :: Floating a => a -> a, trong đó chủ yếu có nghĩa rằng sqrtchỉ có thể chấp nhận số dấu phảy động đầu vào, và do đó Haskell suy ra những gì tôi muốn.

Điều gì xảy ra khi Haskell không thể suy ra những gì tôi muốn? Vâng, có một vài khả năng. Nếu tôi hoàn toàn không sử dụng giá trị trả về, Haskell chỉ đơn giản là không gọi hàm ở vị trí đầu tiên. Tuy nhiên, nếu tôi làm sử dụng giá trị trả về, sau đó Haskell sẽ phàn nàn rằng nó không thể suy ra các loại:

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

Tôi có thể giải quyết sự mơ hồ bằng cách chỉ định loại tôi muốn:

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

Dù sao, toàn bộ cuộc thảo luận này có nghĩa là quá tải bởi giá trị trả về là có thể và được thực hiện, điều này trả lời một phần câu hỏi của bạn.

Phần khác của câu hỏi của bạn là tại sao nhiều ngôn ngữ không làm điều đó. Tôi sẽ để người khác trả lời. Tuy nhiên, một vài ý kiến: lý do chính có lẽ là cơ hội cho sự nhầm lẫn ở đây thực sự lớn hơn so với việc quá tải theo loại đối số. Bạn cũng có thể xem các lý do từ các ngôn ngữ riêng lẻ:

Ada : "Có vẻ như quy tắc giải quyết quá tải đơn giản nhất là sử dụng mọi thứ - tất cả thông tin từ bối cảnh càng rộng càng tốt - để giải quyết tham chiếu quá tải. Quy tắc này có thể đơn giản, nhưng không hữu ích. để quét các đoạn văn bản lớn tùy ý và tạo ra các suy luận phức tạp tùy ý (chẳng hạn như (g) ở trên). Chúng tôi tin rằng một quy tắc tốt hơn là một quy tắc làm rõ ràng nhiệm vụ mà người đọc hoặc trình biên dịch phải thực hiện và điều đó thực hiện nhiệm vụ này càng tự nhiên cho người đọc càng tốt. "

C ++ (tiểu mục 7.4.1of "Ngôn ngữ lập trình C ++" của Bjarne Stroustrup): "Các kiểu trả về không được xem xét trong độ phân giải quá tải. Lý do là để giữ độ phân giải cho một toán tử riêng lẻ hoặc hàm gọi độc lập với ngữ cảnh.

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)
}

Nếu loại trả về đã được tính đến, sẽ không còn có thể xem xét một cuộc gọi sqrt()riêng lẻ và xác định chức năng nào được gọi. "(Lưu ý, để so sánh, trong Haskell không có chuyển đổi ngầm định .)

Java ( Đặc tả ngôn ngữ Java 9.4.1 ): "Một trong các phương thức được kế thừa phải là kiểu trả về thay thế cho mọi phương thức được kế thừa khác, nếu không sẽ xảy ra lỗi thời gian biên dịch." (Vâng, tôi biết điều này không đưa ra một lý do hợp lý. Tôi chắc chắn lý do được đưa ra bởi Gosling trong "Ngôn ngữ lập trình Java". Có lẽ ai đó có một bản sao? Tôi cá là "nguyên tắc ít bất ngờ nhất" về bản chất. ) Tuy nhiên, thực tế thú vị về Java: JVM cho phép quá tải theo giá trị trả về! Điều này được sử dụng, ví dụ, trong Scala và cũng có thể được truy cập trực tiếp thông qua Java bằng cách chơi xung quanh với các phần bên trong.

Tái bút Như một lưu ý cuối cùng, thực sự có thể quá tải bằng giá trị trả về trong C ++ bằng một mẹo. Nhân chứng:

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
}

Nếu các hàm bị quá tải bởi kiểu trả về và bạn có hai lần quá tải này

int func();
string func();

không có cách nào trình biên dịch có thể tìm ra hàm nào trong hai hàm đó để gọi khi thấy một cuộc gọi như thế này

void main() 
{
    func();
}

Vì lý do này, các nhà thiết kế ngôn ngữ thường không cho phép quá tải giá trị trả về.

Một số ngôn ngữ (chẳng hạn như MSIL), tuy nhiên, làm phép quá tải bởi kiểu trả về. Họ cũng phải đối mặt với những khó khăn trên, nhưng họ có cách giải quyết, mà bạn sẽ phải tham khảo tài liệu của họ.

Trong ngôn ngữ như vậy, bạn sẽ giải quyết như thế nào sau đây:

f(g(x))

nếu fđã quá tải void f(int)và void f(string)và gđã quá tải int g(int)và string g(int)? Bạn sẽ cần một số loại disambiguator.

Tôi nghĩ rằng các tình huống mà bạn có thể cần điều này sẽ được phục vụ tốt hơn bằng cách chọn một tên mới cho hàm.

Để đánh cắp một câu trả lời cụ thể của C ++ từ một câu hỏi rất giống nhau (dupe?):

Các kiểu trả về hàm không xuất hiện ở độ phân giải quá tải đơn giản chỉ vì Stroustrup (tôi giả sử với đầu vào từ các kiến ​​trúc sư C ++ khác) muốn độ phân giải quá tải phải 'độc lập với bối cảnh'. Xem 7.4.1 - "Loại quá tải và trả về" từ "Ngôn ngữ lập trình C ++, Ấn bản thứ ba".

Lý do là để giữ độ phân giải cho một toán tử riêng lẻ hoặc chức năng gọi độc lập theo ngữ cảnh.

Họ muốn nó chỉ dựa trên cách gọi quá tải - chứ không phải cách sử dụng kết quả (nếu nó được sử dụng). Thật vậy, nhiều hàm được gọi mà không sử dụng kết quả hoặc kết quả sẽ được sử dụng như một phần của biểu thức lớn hơn. Một yếu tố mà tôi chắc chắn đã phát huy khi họ quyết định điều này là nếu kiểu trả về là một phần của độ phân giải, sẽ có nhiều lệnh gọi đến các hàm quá tải cần được giải quyết bằng các quy tắc phức tạp hoặc sẽ phải ném trình biên dịch một lỗi mà cuộc gọi không rõ ràng

Và, Lord biết, độ phân giải quá tải C ++ đủ phức tạp khi nó đứng ...

Trong haskell, điều đó là có thể mặc dù nó không có chức năng quá tải. Haskell sử dụng các lớp loại. Trong một chương trình bạn có thể thấy:

class Example a where
    example :: Integer -> a

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

Chức năng quá tải bản thân nó không quá phổ biến. Hầu hết các ngôn ngữ tôi đã thấy với nó là C ++, có lẽ java và / hoặc C #. Trong tất cả các ngôn ngữ động, đó là cách viết tắt của:

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()

Do đó, không có nhiều điểm trong đó. Hầu hết mọi người không quan tâm liệu ngôn ngữ có thể giúp bạn bỏ một dòng trên mỗi nơi bạn sử dụng ngôn ngữ đó không.

Kết hợp mẫu có phần giống với nạp chồng hàm và tôi đoán đôi khi hoạt động tương tự. Mặc dù vậy, điều này không phổ biến vì nó chỉ hữu ích cho một số chương trình và khó thực hiện trên hầu hết các ngôn ngữ.

Bạn thấy có vô số các tính năng dễ thực hiện khác tốt hơn để triển khai vào ngôn ngữ, bao gồm:

• Gõ động
• Hỗ trợ nội bộ cho danh sách, từ điển và chuỗi unicode
• Tối ưu hóa (JIT, gõ suy luận, biên dịch)
• Công cụ triển khai tích hợp
• Hỗ trợ thư viện
• Nơi hỗ trợ và thu thập cộng đồng
• Thư viện tiêu chuẩn phong phú
• Cú pháp tốt
• Đọc vòng lặp in eval
• Hỗ trợ lập trình phản chiếu

Câu trả lời tốt! Câu trả lời của A.Rex nói riêng là rất chi tiết và mang tính hướng dẫn. Như ông chỉ ra, C ++ không xem xét khai thác loại chuyển đổi người dùng cung cấp khi biên dịch lhs = func(); (nơi func thực sự là tên của một struct) . Cách giải quyết của tôi hơi khác một chút - không tốt hơn, chỉ khác (mặc dù nó dựa trên cùng một ý tưởng cơ bản).

Trong khi đó tôi đã muốn viết ...

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++!

Tôi đã kết thúc với một giải pháp sử dụng cấu trúc được tham số hóa (với T = kiểu trả về):

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 :)

Một lợi ích của giải pháp này là bất kỳ mã nào bao gồm các định nghĩa mẫu này có thể thêm nhiều chuyên môn hơn cho nhiều loại hơn. Ngoài ra, bạn có thể làm chuyên môn một phần của cấu trúc khi cần thiết. Ví dụ: nếu bạn muốn xử lý đặc biệt cho các loại con trỏ:

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

Như một tiêu cực, bạn không thể viết int x = func();với giải pháp của tôi. Bạn phải viết int x = func<int>();. Bạn phải nói rõ ràng kiểu trả về là gì, thay vì yêu cầu trình biên dịch loại bỏ nó bằng cách xem xét các toán tử chuyển đổi loại. Tôi sẽ nói rằng giải pháp "của tôi" và cả A.Rex đều thuộc về một cách tối ưu pareto để giải quyết vấn đề nan giải C ++ này :)

nếu bạn muốn nạp chồng các phương thức với các kiểu trả về khác nhau, chỉ cần thêm một tham số giả với giá trị mặc định để cho phép thực thi quá tải, nhưng đừng quên loại tham số nên khác nhau để logic quá tải hoạt động tiếp theo là ví dụ trên delphi:

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

sử dụng nó như thế này

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;

Như đã được hiển thị - các lệnh gọi mơ hồ của một hàm chỉ khác nhau bởi kiểu trả về giới thiệu sự mơ hồ. Sự mơ hồ gây ra mã bị lỗi. Mã lỗi phải tránh

Sự phức tạp được thúc đẩy bởi nỗ lực mơ hồ cho thấy đây không phải là một vụ hack tốt. Ngoài một bài tập trí tuệ - tại sao không sử dụng các thủ tục với các tham số tham chiếu.

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

tính năng quá tải này không khó để quản lý, nếu bạn nhìn nó theo một cách hơi khác. xem xét những điều sau đây

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

nếu một ngôn ngữ đã trả lại quá tải, nó sẽ cho phép quá tải tham số, nhưng không trùng lặp. điều này sẽ giải quyết vấn đề:

main (){
f(x)
}

bởi vì chỉ có một f (int sự lựa chọn) để lựa chọn.

Trong .NET, đôi khi chúng tôi sử dụng một tham số để chỉ ra đầu ra mong muốn từ kết quả chung và sau đó thực hiện chuyển đổi để có được những gì chúng tôi mong đợi.

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();
    }

Có lẽ ví dụ này cũng có thể giúp:

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;
}

Đối với bản ghi, Octave cho phép kết quả khác nhau tùy theo phần tử trả về là vô hướng so với mảng.

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

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

Cf cũng phân tách giá trị số ít .

Cái này hơi khác với C ++; Tôi không biết nếu nó được coi là quá tải bằng cách trả về trực tiếp. Đó là nhiều hơn một chuyên môn mẫu hoạt động theo cách.

tận dụng

#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

tận dụng

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;    
}

tận dụng

#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;
}

Ví dụ này không chính xác sử dụng độ phân giải quá tải hàm theo kiểu trả về, tuy nhiên lớp không đối tượng c ++ này đang sử dụng chuyên môn hóa mẫu để mô phỏng độ phân giải quá tải hàm theo kiểu trả về với phương thức tĩnh riêng.

Mỗi convertToTypehàm đang gọi mẫu hàm stringToValue()và nếu bạn nhìn vào chi tiết triển khai hoặc thuật toán của mẫu hàm này thì nó đang gọi getValue<T>( param, param )và nó sẽ trả về một kiểu Tvà lưu nó vào một kiểu T*được truyền vàostringToValue() mẫu hàm như một trong các tham số của nó .

Khác với những thứ như thế này; C ++ không thực sự có một cơ chế để có chức năng giải quyết quá tải theo kiểu trả về. Có thể có các cấu trúc hoặc cơ chế khác mà tôi không biết có thể mô phỏng độ phân giải theo kiểu trả về.

Tôi nghĩ rằng đây là một GAP trong định nghĩa C ++ hiện đại tại sao?

int func();
double func();

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

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

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

Tại sao trình biên dịch C ++ không thể đưa ra lỗi trong ví dụ "3" và chấp nhận mã trong ví dụ "1 + 2" ??

Hầu hết các ngôn ngữ tĩnh hiện nay cũng hỗ trợ thuốc generic, sẽ giải quyết vấn đề của bạn. Như đã nêu trước đây, không có tham số khác, không có cách nào để biết nên gọi cái nào. Vì vậy, nếu bạn muốn làm điều này, chỉ cần sử dụng thuốc generic và gọi nó là một ngày.