Chuyển con trỏ được chia sẻ làm đối số

Nếu tôi khai báo một đối tượng được bao bọc trong một con trỏ dùng chung:

std::shared_ptr<myClass> myClassObject(new myClass());

thì tôi muốn chuyển nó làm đối số cho một phương thức:

DoSomething(myClassObject);

//the called method
void DoSomething(std::shared_ptr<myClass> arg1)
{
   arg1->someField = 4;
}

Điều trên có chỉ đơn giản là tăng số lượng tham chiếu của shared_pt và mọi thứ đều tuyệt không? Hay nó để lại một con trỏ lơ lửng?

Bạn vẫn phải làm điều này ?:

DoSomething(myClassObject.Get());

void DoSomething(std::shared_ptr<myClass>* arg1)
{
   (*arg1)->someField = 4;
}

Tôi nghĩ rằng cách thứ 2 có thể hiệu quả hơn vì nó chỉ phải sao chép 1 địa chỉ (trái ngược với toàn bộ con trỏ thông minh), nhưng cách thứ nhất có vẻ dễ đọc hơn và tôi không dự đoán sẽ đẩy giới hạn hiệu suất. Tôi chỉ muốn đảm bảo rằng không có điều gì nguy hiểm về nó.

Cảm ơn bạn.

Tôi muốn chuyển một con trỏ dùng chung cho một hàm. Bạn có thể giúp tôi với đó?

Chắc chắn, tôi có thể giúp bạn điều đó. Tôi giả sử bạn có một số hiểu biết về ngữ nghĩa quyền sở hữu trong C ++. Có đúng như vậy không?

Vâng, tôi hoàn toàn thoải mái với chủ đề này.

Tốt.

Được rồi, tôi chỉ có thể nghĩ ra hai lý do để shared_ptrtranh luận:

1. Hàm muốn chia sẻ quyền sở hữu đối tượng;
2. Hàm thực hiện một số thao tác hoạt động cụ thể trên shared_ptrs.

Bạn quan tâm đến cái nào?

Tôi đang tìm kiếm một câu trả lời chung, vì vậy tôi thực sự quan tâm đến cả hai. Tuy nhiên, tôi tò mò về ý của bạn trong trường hợp số 2.

Ví dụ về các hàm như vậy bao gồm std::static_pointer_cast, bộ so sánh tùy chỉnh hoặc vị từ. Ví dụ: nếu bạn cần tìm tất cả shared_ptr duy nhất từ ​​một vectơ, bạn cần một vị từ như vậy.

À, khi hàm thực sự cần tự thao tác con trỏ thông minh.

Chính xác.

Trong trường hợp đó, tôi nghĩ chúng ta nên chuyển qua tham chiếu.

Đúng. Và nếu nó không thay đổi con trỏ, bạn muốn chuyển bằng tham chiếu const. Không cần sao chép vì bạn không cần chia sẻ quyền sở hữu. Đó là một kịch bản khác.

OK đã nhận nó. Hãy nói về kịch bản khác.

Người mà bạn chia sẻ quyền sở hữu? Đồng ý. Làm thế nào để bạn chia sẻ quyền sở hữu shared_ptr?

Bằng cách sao chép nó.

Sau đó, hàm sẽ cần tạo một bản sao của a shared_ptr, đúng không?

Chắc chắn. Vì vậy, tôi chuyển nó bằng một tham chiếu đến const và sao chép vào một biến cục bộ?

Không, đó là một sự bi quan. Nếu nó được truyền bằng tham chiếu, hàm sẽ không có lựa chọn nào khác ngoài việc tạo bản sao theo cách thủ công. Nếu nó được chuyển theo giá trị, trình biên dịch sẽ chọn lựa chọn tốt nhất giữa một bản sao và một lần di chuyển và thực hiện nó tự động. Vì vậy, hãy vượt qua giá trị.

Điểm tốt. Tôi phải nhớ rằng bài viết " Muốn Tốc độ? Vượt qua Giá trị. " Thường xuyên hơn.

Chờ đã, điều gì sẽ xảy ra nếu hàm lưu trữ shared_ptrtrong một biến thành viên, chẳng hạn? Điều đó sẽ không tạo ra một bản sao thừa phải không?

Hàm có thể chỉ cần di chuyển shared_ptrđối số vào bộ nhớ của nó. Di chuyển a shared_ptrlà rẻ vì nó không thay đổi bất kỳ số lượng tham chiếu nào.

À, ý kiến ​​hay.

Nhưng tôi đang nghĩ đến một kịch bản thứ ba: điều gì sẽ xảy ra nếu bạn không muốn thao túng shared_ptrhoặc chia sẻ quyền sở hữu?

Trong trường hợp đó, shared_ptrhoàn toàn không liên quan đến chức năng. Nếu bạn muốn thao túng con trỏ, hãy lấy con trỏ và để người gọi chọn ngữ nghĩa quyền sở hữu mà họ muốn.

Và tôi nên lấy pointee theo tham chiếu hay theo giá trị?

Các quy tắc thông thường được áp dụng. Con trỏ thông minh không thay đổi bất cứ điều gì.

Chuyển theo giá trị nếu tôi định sao chép, chuyển bằng tham chiếu nếu tôi muốn tránh sao chép.

Đúng.

Hừ! Tôi nghĩ bạn đã quên một kịch bản khác. Nếu tôi muốn chia sẻ quyền sở hữu, nhưng chỉ phụ thuộc vào một điều kiện nhất định thì sao?

Ah, một trường hợp cạnh thú vị. Tôi không mong điều đó xảy ra thường xuyên. Nhưng khi nó xảy ra, bạn có thể chuyển theo giá trị và bỏ qua bản sao nếu bạn không cần nó hoặc chuyển bằng tham chiếu và tạo bản sao nếu bạn cần.

Tôi mạo hiểm với một bản sao thừa trong tùy chọn đầu tiên và mất một nước đi tiềm năng trong tùy chọn thứ hai. Tôi không thể ăn bánh và có nó nữa?

Nếu bạn đang ở trong tình huống thực sự quan trọng, bạn có thể cung cấp hai quá tải, một lấy tham chiếu const lvalue và một lấy tham chiếu rvalue. Một bản sao, bản khác di chuyển. Một mẫu hàm chuyển tiếp hoàn hảo là một tùy chọn khác.

Tôi nghĩ rằng điều đó bao gồm tất cả các tình huống có thể xảy ra. Cảm ơn rât nhiều.

Tôi nghĩ rằng mọi người sợ hãi một cách không cần thiết về việc sử dụng con trỏ thô làm tham số hàm. Nếu hàm sẽ không lưu trữ con trỏ hoặc ảnh hưởng đến thời gian tồn tại của nó, một con trỏ thô hoạt động tốt và đại diện cho mẫu số chung thấp nhất. Hãy xem xét ví dụ như cách bạn truyền a unique_ptrvào một hàm nhận a shared_ptrlàm tham số, theo giá trị hoặc bằng tham chiếu const?

void DoSomething(myClass * p);

DoSomething(myClass_shared_ptr.get());
DoSomething(myClass_unique_ptr.get());

Con trỏ thô làm tham số hàm không ngăn cản bạn sử dụng con trỏ thông minh trong mã gọi, nơi nó thực sự quan trọng.

Vâng, toàn bộ ý tưởng về shared_ptr <> là nhiều phiên bản có thể chứa cùng một con trỏ thô và bộ nhớ bên dưới sẽ chỉ được giải phóng khi phiên bản cuối cùng của shared_ptr <> bị phá hủy.

Tôi sẽ tránh một con trỏ đến shared_ptr <> vì điều đó làm mất mục đích vì bạn đang xử lý lại raw_pointers.

Truyền giá trị trong ví dụ đầu tiên của bạn là an toàn nhưng có một thành ngữ hay hơn. Chuyển qua tham chiếu const khi có thể - tôi sẽ nói có ngay cả khi xử lý con trỏ thông minh. Ví dụ thứ hai của bạn không chính xác bị hỏng nhưng nó rất !???. Ngớ ngẩn, không hoàn thành bất cứ điều gì và đánh bại một phần quan điểm của những con trỏ thông minh, và sẽ khiến bạn rơi vào một thế giới đầy đau khổ khi bạn cố gắng tham khảo và sửa đổi mọi thứ.

trong hàm của DoSomething bạn, bạn đang thay đổi một thành viên dữ liệu của một thể hiện của lớp, myClass vì vậy những gì bạn đang sửa đổi là đối tượng được quản lý (con trỏ thô) chứ không phải đối tượng (shared_ptr). Có nghĩa là tại điểm trả về của hàm này, tất cả các con trỏ dùng chung đến con trỏ thô được quản lý sẽ thấy thành viên dữ liệu của chúng: myClass::someFieldđã thay đổi thành một giá trị khác.

trong trường hợp này, bạn đang truyền một đối tượng cho một hàm với đảm bảo rằng bạn không sửa đổi nó (nói về shared_ptr không phải đối tượng sở hữu).

Thành ngữ để diễn đạt điều này là: a const ref, like so

void DoSomething(const std::shared_ptr<myClass>& arg)

Tương tự như vậy, bạn đang đảm bảo với người dùng chức năng của mình, rằng bạn không thêm chủ sở hữu khác vào danh sách chủ sở hữu của con trỏ thô. Tuy nhiên, bạn vẫn có khả năng sửa đổi đối tượng cơ bản được trỏ tới bởi con trỏ thô.

CAVEAT: Có nghĩa là, nếu bằng một cách nào đó ai đó gọi shared_ptr::resettrước khi bạn gọi hàm của bạn và tại thời điểm đó là shared_ptr cuối cùng sở hữu raw_ptr, thì đối tượng của bạn sẽ bị phá hủy và hàm của bạn sẽ thao tác một Con trỏ lơ lửng đến đối tượng bị phá hủy. RẤT NGUY HIỂM!!!