Có lợi ích gì khi chuyển bằng con trỏ qua chuyển qua tham chiếu trong C ++ không?

Những lợi ích của việc chuyển bằng con trỏ qua chuyển qua tham chiếu trong C ++ là gì?

Gần đây, tôi đã thấy một số ví dụ chọn truyền các đối số hàm bằng con trỏ thay vì chuyển qua tham chiếu. Có lợi ích để làm điều này?

Thí dụ:

func(SPRITE *x);

với một cuộc gọi của

func(&mySprite);

so với

func(SPRITE &x);

với một cuộc gọi của

func(mySprite);

Một con trỏ có thể nhận được một tham số NULL, một tham số không thể. Nếu có cơ hội bạn có thể muốn vượt qua "không có đối tượng", thì hãy sử dụng một con trỏ thay vì tham chiếu.

Ngoài ra, chuyển qua con trỏ cho phép bạn nhìn rõ ràng tại trang web cuộc gọi cho dù đối tượng được truyền theo giá trị hoặc bằng tham chiếu:

// Is mySprite passed by value or by reference?  You can't tell 
// without looking at the definition of func()
func(mySprite);

// func2 passes "by pointer" - no need to look up function definition
func2(&mySprite);

Đi qua con trỏ

• Người gọi phải lấy địa chỉ -> không minh bạch
• Giá trị 0 có thể được cung cấp có nghĩa nothing. Điều này có thể được sử dụng để cung cấp các đối số tùy chọn.

Đi qua tham khảo

• Người gọi chỉ cần vượt qua đối tượng -> trong suốt. Phải được sử dụng cho quá tải toán tử, vì quá tải cho các loại con trỏ là không thể (con trỏ là loại dựng sẵn). Vì vậy, bạn không thể làm string s = &str1 + &str2; sử dụng con trỏ.
• Không có giá trị 0 nào -> Hàm được gọi không phải kiểm tra chúng
• Tham chiếu đến const cũng chấp nhận tạm thời: void f(const T& t); ... f(T(a, b, c)); , con trỏ không thể được sử dụng như thế vì bạn không thể lấy địa chỉ tạm thời.
• Cuối cùng nhưng không kém phần quan trọng, các tài liệu tham khảo dễ sử dụng hơn -> ít cơ hội hơn cho các lỗi.

Tôi thích lý do bởi một bài viết từ "cplusplus.com:"

1. Truyền theo giá trị khi hàm không muốn sửa đổi tham số và giá trị dễ sao chép (ints, double, char, bool, v.v ... các loại đơn giản. Std :: string, std :: vector và tất cả các STL khác container KHÔNG phải là loại đơn giản.)

2. Chuyển qua con trỏ const khi giá trị đắt để sao chép VÀ hàm không muốn sửa đổi giá trị được trỏ đến AND NULL là giá trị hợp lệ, được mong đợi mà hàm xử lý.

3. Truyền bằng con trỏ không const khi giá trị đắt để sao chép VÀ hàm muốn sửa đổi giá trị được trỏ đến AND NULL là giá trị được mong đợi, hợp lệ mà hàm xử lý.

4. Chuyển qua tham chiếu const khi giá trị đắt để sao chép VÀ hàm không muốn sửa đổi giá trị được đề cập VÀ NULL sẽ không phải là giá trị hợp lệ nếu sử dụng con trỏ thay thế.

5. Chuyển qua tham chiếu không liên quan khi giá trị đắt để sao chép VÀ hàm muốn sửa đổi giá trị được đề cập VÀ NULL sẽ không phải là giá trị hợp lệ nếu sử dụng con trỏ thay thế.

6. Khi viết các hàm mẫu, không có câu trả lời rõ ràng vì có một vài sự đánh đổi để xem xét nằm ngoài phạm vi của cuộc thảo luận này, nhưng đủ để nói rằng hầu hết các hàm mẫu lấy tham số của chúng theo giá trị hoặc tham chiếu (const) , tuy nhiên vì cú pháp của trình lặp tương tự như cú pháp của con trỏ (dấu hoa thị cho "dereference"), nên bất kỳ hàm mẫu nào mong đợi các trình lặp như là đối số cũng sẽ mặc định chấp nhận con trỏ (và không kiểm tra NULL vì khái niệm Trình lặp NULL có cú pháp khác ).

http://www.cplusplus.com/articles/z6vU7k9E/

Điều tôi nhận được từ điều này là sự khác biệt chính giữa việc chọn sử dụng một con trỏ hoặc tham số tham chiếu là nếu NULL là một giá trị chấp nhận được. Đó là nó.

Cho dù giá trị là đầu vào, đầu ra, có thể sửa đổi, vv nên được đưa vào tài liệu / nhận xét về chức năng.

"Đủ dây để tự bắn vào chân" của Allen Holub liệt kê 2 quy tắc sau:

120. Reference arguments should always be `const`
121. Never use references as outputs, use pointers

Ông liệt kê một số lý do tại sao các tài liệu tham khảo đã được thêm vào C ++:

• chúng là cần thiết để xác định các hàm tạo sao chép
• chúng là cần thiết cho quá tải nhà điều hành
• const tài liệu tham khảo cho phép bạn có ngữ nghĩa pass-by-value trong khi tránh một bản sao

Quan điểm chính của ông là các tham chiếu không nên được sử dụng làm tham số 'đầu ra' bởi vì tại trang web cuộc gọi không có dấu hiệu nào cho biết tham số đó là tham chiếu hay tham số giá trị. Vì vậy, quy tắc của ông là chỉ sử dụngconst tài liệu tham khảo như là đối số.

Cá nhân, tôi nghĩ rằng đây là một quy tắc tốt vì nó làm cho nó rõ ràng hơn khi một tham số là một tham số đầu ra hay không. Tuy nhiên, trong khi cá nhân tôi đồng ý với điều này nói chung, tôi cho phép bản thân bị ảnh hưởng bởi ý kiến ​​của những người khác trong nhóm của mình nếu họ tranh luận về các tham số đầu ra là tài liệu tham khảo (một số nhà phát triển thích chúng).

Làm rõ các bài viết trước:

Tài liệu tham khảo KHÔNG là sự đảm bảo để có được một con trỏ không null. (Mặc dù chúng ta thường đối xử với họ như vậy.)

Trong khi mã xấu khủng khiếp, như đưa bạn ra đằng sau mã xấu bị khắc gỗ , phần sau đây sẽ biên dịch và chạy: (Ít nhất là dưới trình biên dịch của tôi.)

bool test( int & a)
{
  return (&a) == (int *) NULL;
}

int
main()
{
  int * i = (int *)NULL;
  cout << ( test(*i) ) << endl;
};

Vấn đề thực sự tôi gặp phải với các tài liệu tham khảo nằm ở các lập trình viên khác, từ đó được gọi là IDIOTS , người phân bổ trong hàm tạo, phân bổ trong hàm hủy và không cung cấp hàm tạo hoặc toán tử sao chép = ().

Đột nhiên, có một thế giới khác biệt giữa foo (thanh BAR) và foo (BAR & bar) . (Hoạt động sao chép bitwise tự động được gọi. Giao dịch trong hàm hủy được gọi hai lần.)

Rất may các trình biên dịch hiện đại sẽ nhận được sự phân chia kép này của cùng một con trỏ. 15 năm trước, họ đã không làm thế. (Trong gcc / g ++, sử dụng setenv MALLOC_CHECK_ 0 để xem lại các cách cũ.) Kết quả, theo DEC UNIX, trong cùng một bộ nhớ được phân bổ cho hai đối tượng khác nhau. Có rất nhiều trò vui gỡ lỗi ở đó ...

Thực tế hơn:

• Tài liệu tham khảo ẩn rằng bạn đang thay đổi dữ liệu được lưu trữ ở một nơi khác.
• Thật dễ dàng để nhầm lẫn một Tài liệu tham khảo với một đối tượng Sao chép.
• Con trỏ làm cho nó rõ ràng!

Hầu hết các câu trả lời ở đây không giải quyết được sự mơ hồ vốn có trong việc có một con trỏ thô trong chữ ký hàm, về mặt thể hiện ý định. Các vấn đề như sau:

• Người gọi không biết liệu con trỏ trỏ đến một đối tượng hay bắt đầu một "mảng" của các đối tượng.

• Người gọi không biết liệu con trỏ có "sở hữu" bộ nhớ mà nó trỏ tới hay không. IE, có hay không chức năng sẽ giải phóng bộ nhớ. ( foo(new int)- Đây có phải là rò rỉ bộ nhớ không?).

• Người gọi không biết liệu nullptrcó thể được truyền an toàn vào chức năng hay không.

Tất cả những vấn đề này được giải quyết bằng cách tham khảo:

• Tài liệu tham khảo luôn đề cập đến một đối tượng duy nhất.

• Tài liệu tham khảo không bao giờ sở hữu bộ nhớ mà chúng đề cập đến, chúng chỉ đơn thuần là một cái nhìn vào bộ nhớ.

• Tài liệu tham khảo không thể rỗng.

Điều này làm cho tài liệu tham khảo một ứng cử viên tốt hơn nhiều cho sử dụng chung. Tuy nhiên, tài liệu tham khảo không hoàn hảo - có một vài vấn đề lớn cần xem xét.

• Không có quyết định rõ ràng. Đây không phải là vấn đề với một con trỏ thô, vì chúng ta phải sử dụng &toán tử để cho thấy rằng chúng ta thực sự đang vượt qua một con trỏ. Ví dụ, int a = 5; foo(a);không rõ ràng ở đây rằng a đang được thông qua tham chiếu và có thể được sửa đổi.
• Tính không ổn định. Điểm yếu này của con trỏ cũng có thể là một điểm mạnh, khi chúng ta thực sự muốn các tài liệu tham khảo của mình là null. Xem như std::optional<T&>không hợp lệ (vì lý do chính đáng), con trỏ cung cấp cho chúng tôi tính vô hiệu mà bạn muốn.

Vì vậy, có vẻ như khi chúng ta muốn một tài liệu tham khảo vô giá trị với sự gián tiếp rõ ràng, chúng ta nên đạt được một T*quyền? Sai lầm!

Trừu tượng

Trong sự tuyệt vọng của chúng tôi về sự vô hiệu, chúng tôi có thể tiếp cận T*và chỉ cần bỏ qua tất cả những thiếu sót và sự mơ hồ ngữ nghĩa được liệt kê trước đó. Thay vào đó, chúng ta nên tiếp cận với những gì C ++ làm tốt nhất: một sự trừu tượng hóa. Nếu chúng ta chỉ đơn giản viết một lớp bao quanh một con trỏ, chúng ta sẽ có được tính biểu cảm, cũng như tính vô hiệu và không rõ ràng.

template <typename T>
struct optional_ref {
  optional_ref() : ptr(nullptr) {}
  optional_ref(T* t) : ptr(t) {}
  optional_ref(std::nullptr_t) : ptr(nullptr) {}

  T& get() const {
    return *ptr;
  }

  explicit operator bool() const {
    return bool(ptr);
  }

private:
  T* ptr;
};

Đây là giao diện đơn giản nhất tôi có thể nghĩ ra, nhưng nó thực hiện công việc một cách hiệu quả. Nó cho phép khởi tạo tham chiếu, kiểm tra xem một giá trị có tồn tại và truy cập giá trị đó không. Chúng ta có thể sử dụng nó như vậy:

void foo(optional_ref<int> x) {
  if (x) {
    auto y = x.get();
    // use y here
  }
}

int x = 5;
foo(&x); // explicit indirection here
foo(nullptr); // nullability

Chúng tôi đã đạt được mục tiêu của chúng tôi! Bây giờ chúng ta hãy xem các lợi ích, so với con trỏ thô.

• Giao diện hiển thị rõ ràng rằng tham chiếu chỉ nên tham chiếu đến một đối tượng.
• Rõ ràng nó không sở hữu bộ nhớ mà nó đề cập đến, vì nó không có hàm hủy do người dùng định nghĩa và không có phương thức để xóa bộ nhớ.
• Người gọi biết nullptrcó thể được thông qua, vì tác giả hàm rõ ràng đang yêu cầu mộtoptional_ref

Chúng ta có thể làm cho giao diện phức tạp hơn từ đây, chẳng hạn như thêm toán tử đẳng thức, giao diện đơn get_orvà mapgiao diện, một phương thức nhận giá trị hoặc ném ngoại lệ,constexpr hỗ trợ. Điều đó có thể được thực hiện bởi bạn.

Tóm lại, thay vì sử dụng các con trỏ thô, hãy suy luận về ý nghĩa của những con trỏ đó trong mã của bạn và tận dụng sự trừu tượng của thư viện tiêu chuẩn hoặc viết riêng của bạn. Điều này sẽ cải thiện mã của bạn đáng kể.

Không hẳn vậy. Trong nội bộ, chuyển qua tham chiếu được thực hiện bằng cách chủ yếu chuyển địa chỉ của đối tượng được tham chiếu. Vì vậy, thực sự không có bất kỳ lợi ích hiệu quả nào có được bằng cách vượt qua một con trỏ.

Đi qua tham chiếu có một lợi ích, tuy nhiên. Bạn được đảm bảo có một thể hiện của bất kỳ đối tượng / loại nào đang được truyền vào. Nếu bạn truyền vào một con trỏ, thì bạn có nguy cơ nhận được một con trỏ NULL. Bằng cách sử dụng tham chiếu qua, bạn đang đẩy một NULL ẩn - kiểm tra một cấp cho người gọi hàm của bạn.