Tôi có một số std::unique_ptr và một con trỏ thô khác. Tôi muốn con trỏ thô trỏ đến nội dung của unique_ptr mà không có bất kỳ loại quyền sở hữu nào. Đó là mối quan hệ chỉ đọc:Chỉ đến nội dung của tiêu chuẩn :: unique_ptr
auto bar=std::make_unique<foo>();
auto ptr=bar.get();// This may point to another value later
Điều này có tệ không? Có cách nào khác không?
Lưu ý: ví dụ thực tế phức tạp hơn. Họ không cùng lớp.
Nếu bạn có thể đảm bảo rằng A)bar 's đời sẽ vượt quá tuổi thọ của ptr VÀ B) rằng không có lập trình viên/refactoring bao giờ sẽ viết delete ptr; bất cứ lúc nào, thì đây là hoàn toàn tốt đẹp và có lẽ lý tưởng cho mọi tình huống mà bạn cần truyền con trỏ mà không có quyền sở hữu.
Nếu hai điều kiện này không thể được đảm bảo, có thể bạn đang sử dụng std::shared_ptr và std::weak_ptr.
Và có lẽ bạn không nên sử dụng 'shared_ptr', bởi vì 99%" chờ đợi, tôi có thể giải quyết các vấn đề về tài nguyên của tôi với 'shared_ptr'" kết thúc là một ý tưởng tồi. – Yakk
@Yakk Tốt nhất, tôi sẽ gọi là hyperbolic, và tệ nhất, ngây thơ. Tôi đã gặp phải nhiều vấn đề trong đất C++, nơi giải pháp tốt nhất, thành ngữ nhất được gọi là 'std :: shared_ptr'. Tôi sẽ cho bạn rằng sự phụ thuộc vào con trỏ ở nơi đầu tiên có xu hướng đại diện cho một nguyên nhân (hoặc triệu chứng) của độ phức tạp thiết kế, nhưng nếu chúng là '99% thời gian' tồi tệ, Java (cơ bản sử dụng các đối tượng giống như shared_ptr' cho tất cả các con trỏ của nó) sẽ không thể sử dụng như một ngôn ngữ, và chúng ta biết rằng không phải như vậy. – Xirema
Chúng ta có thực sự biết điều đó không? Nhưng nghiêm túc, Java sử dụng con trỏ gc đầy đủ, đó là một con thú khác với con trỏ rc. Suy nghĩ về con trỏ rc như một số loại con trỏ gc thực sự là một dấu hiệu của một lỗi cơ bản trong thiết kế của một thành phần, và các lỗi như vậy là một phần của 99% đó. Tôi đã tìm thấy các tình huống mà con trỏ chia sẻ là đúng (khi bạn có * quyền sở hữu chia sẻ * của một số tài nguyên, không chỉ là "Tôi không muốn nghĩ về vấn đề con trỏ ở đây"), nhưng hiếm khi được giải quyết bằng cách chỉ đơn giản là xẻng các con trỏ được chia sẻ và yếu vào hệ thống. – Yakk
Không, không tệ, và cho đến khi thư viện chuẩn kết hợp proposed std::observer_ptr, đó là cách thành ngữ thể hiện một người quan sát không sở hữu.
Và ngay cả sau đó, nó sẽ là cách thành ngữ đại diện cho điều đó. Nguyên tắc Core C++ không nói để sử dụng 'observer_ptr'; họ nói rằng tất cả các 'T *' trần truồng đại diện cho không sở hữu. –
@NicolBolas Đó là một câu hỏi liệu họ sẽ vẫn nói rằng sau khi 'std :: experiment :: observer_ptr' trở thành' std :: observer_ptr'. Tôi có thể hình dung hướng dẫn chuyển thành "đọc' T * "là không sở hữu, nhưng viết không sở hữu là' std :: observer_ptr
"* Đó là câu hỏi liệu họ sẽ vẫn nói rằng sau khi' std :: experimental :: observer_ptr' trở thành 'std :: observer_ptr'. *" Và đó là câu hỏi liệu điều đó có thực sự xảy ra hay không; Sự thay đổi của TS giữa việc được đề xuất và được áp dụng vào tiêu chuẩn cốt lõi. Ngoài ra, điều đó sẽ không biến đổi một cách kỳ diệu * hàng tỷ * các dòng mã C++ hiện có sử dụng con trỏ trần cho các con trỏ chưa được chú ý. –
Không nên là 'bar.get();'? –
@ πάνταῥεῖ có xin lỗi –
Tôi muốn nói điều này là lý tưởng. Nhưng tôi có lẽ sẽ chọn một tên khác vì đã có một 'std :: weak_ptr' với các ngữ nghĩa khác nhau. – Galik