Cảnh báo gcc phụ: loại vòng loại trên hàm trả về

Question

Khi tôi biên dịch mã C++ với GCC 4.3 lần đầu tiên, (sau khi biên dịch thành công mà không có cảnh báo trên 4.1, 4.0, 3.4 với tùy chọn -Wall -Wextra) một loạt các lỗi của biểu mẫu warning: type qualifiers ignored on function return type.

Cân nhắc temp.cpp:

class Something 
{ 
public: 
    const int getConstThing() const { 
     return _cMyInt; 
    } 
    const int getNonconstThing() const { 
     return _myInt; 
    } 

    const int& getConstReference() const { 
     return _myInt; 
    } 
    int& getNonconstReference() { 
     return _myInt; 
    } 

    void setInt(const int newValue) { 
     _myInt = newValue; 
    } 

    Something() : _cMyInt(3) { 
     _myInt = 2; 
    } 
private: 
    const int _cMyInt; 
    int _myInt; 
}; 

Chạy g++ temp.cpp -Wextra -c -o blah.o:

temp.cpp:4: warning: type qualifiers ignored on function return type 
temp.cpp:7: warning: type qualifiers ignored on function return type 

Ai đó có thể cho tôi biết những gì tôi đang làm sai mà vi phạm các tiêu chuẩn C++? Tôi cho rằng khi trở về theo giá trị, số const hàng đầu là thừa, nhưng tôi không hiểu tại sao cần phải tạo cảnh báo với nó. Có những nơi khác mà tôi nên rời khỏi const?

Answer 1

Nó không vi phạm tiêu chuẩn. Đó là lý do tại sao họ cảnh báo và không phải lỗi.

Và thực sự bạn đã đúng - số const hàng đầu là không cần thiết. Trình biên dịch cảnh báo bạn bởi vì bạn đã thêm mã trong các trường hợp khác có thể có nghĩa là gì đó, nhưng trong hoàn cảnh này có nghĩa là không có gì, và nó muốn đảm bảo bạn sẽ không thất vọng sau khi các giá trị trả lại của bạn có thể sửa đổi được sau tất cả.

Answer 2

Tôi đã gặp cảnh báo này khi biên dịch một số mã sử dụng Boost.ProgramOptions. Tôi sử dụng -Werror để cảnh báo đã giết chết bản dựng của tôi, nhưng vì nguồn gốc của cảnh báo ở độ sâu của Boost tôi không thể loại bỏ nó bằng cách sửa đổi mã của tôi.

Sau nhiều đào tôi thấy tùy chọn trình biên dịch mà vô hiệu hóa các cảnh báo:

-Wno-ignored-qualifiers 

Hope this helps.

Answer 3

Scott Meyers chỉ ra rằng có lý do khá tốt lý do ai đó muốn trả lại giá trị const. Dưới đây là ví dụ:

int some_calculation(int a, int b) { int res = 0; /* ... */ return res; } 

/* Test if the result of the calculation equals 40.*/ 
if (some_calculation(3,20) = 40) 
{ 

} 

Bạn có thấy những gì tôi đã làm sai không? Mã này là hoàn toàn chính xác và nên biên dịch. Vấn đề là trình biên dịch không hiểu rằng bạn dự định để so sánh thay vì gán giá trị 40.

Với giá trị trả về const ví dụ trên sẽ không biên dịch. Vâng, ít nhất là nếu trình biên dịch không loại bỏ từ khóa const.

Answer 4

Có này

struct Foo { Foo(int) {} operator bool() { return true; } };

và

Foo some_calculation(int a, int b) { Foo result(a + b); /*...*/ return result; }

ví dụ

if (some_calculation(3, 20) = 40) { /*...*/ }

biên dịch mà không có một cảnh báo. Tất nhiên, điều này là hiếm. Nhưng không phải là const đúng đắn về việc làm cho nó khó khăn cho mọi người làm những việc sai? Và với kỳ vọng rằng mọi người thử mọi thứ, điều đó sai, kiểu trả về phải được khai báo const. Và: g ++ cảnh báo về việc bỏ qua trình phân loại, nhưng không bỏ qua nó. Tôi nghĩ, cảnh báo là về người dùng lấy bản sao và bỏ qua các bộ phân loại const trên bản sao của họ. Nhưng đó không phải là một cảnh báo, bởi vì đây là hành vi hoàn toàn chính xác. Và nó có ý nghĩa để làm điều này.

Answer 5

Không nên sử dụng sai ngữ cảnh cho phép tuân thủ nghiêm ngặt tiêu chuẩn ISO? Tùy thuộc vào = -std tất nhiên ...

Answer 6

Cảnh báo này cũng rất hữu ích để tránh nhầm lẫn khi tuyên bố chức năng trở về con trỏ đến đối tượng mà không nên được sửa đổi:

// "warning: type qualifiers ignored on function return type" 
// as the pointer is copied. 
Foo* const bar(); 

// correct: 
const Foo* bar(); 

Answer 7

Trả về một giá trị không đổi chỉ có ý nghĩa khi bạn trả về một tham chiếu hoặc một con trỏ (trong trường hợp này con trỏ đến hằng số và không phải là một con trỏ liên tục) bởi vì người gọi có thể sửa đổi giá trị tham chiếu (được trỏ tới).

Một bình luận trên các mã không liên quan đến câu hỏi của bạn: Tôi nghĩ rằng nó tốt hơn để sử dụng một setter thay vì

int& getNonconstReference() { 
    return _myInt; 
} 

nào nên sẽ là:

void setMyInt(int n) { 
    _myInt = n; 
} 

Hơn nữa, nó vô dụng để trả về tham chiếu const cho một int. Nó có ý nghĩa đối với một đối tượng lớn hơn có bản sao hoặc di chuyển đắt hơn.

Answer 8

Có sự khác biệt giữa const về kết quả loại cơ bản, trong đó nó bị bỏ qua và const trên kết quả loại lớp, nơi nó thường tàn phá.

namespace i { 
    auto f() -> int const { return 42; } 
    void g(int&&) {} 
} 

namespace s { 
    struct S {}; 
    auto f() -> S const { return {}; } 
    auto g(S&& ) {} 
} 

auto main() -> int 
{ 
    { using namespace i; g(f()); } // OK 
    { using namespace s; g(f()); } // !The `const` prevents this. 
} 

Đây là lý do tại sao trình biên dịch cảnh báo trong trường hợp đầu tiên: đó là trường hợp đặc biệt, có thể không làm được điều mà một người có thể mong đợi.

Để lập trình hiện đại, IMHO cũng sẽ tốt đẹp với cảnh báo về const về kết quả loại lớp vì nó cấm di chuyển ngữ nghĩa; một chi phí khá nghiêm trọng cho bất kỳ lợi thế nhỏ nào được hình dung.