库 API 获取 weak_ptr(s) 作为输入参数是否合理？
Is it reasonable for a library API to get weak_ptr(s) as the input parameter(s)?
我正在使用 C++ 库的 API，它需要大量 std::weak_ptr 作为 API 方法的输入参数。库 不保留 这些指针，只是对它们进行一些处理。对我来说，从图书馆的角度来看，这个设计是这样的：
Hi API User,
You have passed me some weak pointers as the input parameter(s) of
a method to get a service from the library. But your pointers may be expired and not
valid anymore. OK, no problem, I will do the check and let you know
about it.
BR,
Library API
这样一个API的设计，用一个std::shared_ptr获取所有的指针不是更合理吗？在这种情况下，如果 API 用户正在使用 weak_ptrs，则用户有责任首先 .lock() weak_ptr 指针，然后将它们传递给 API（如果 .lock() 成功）。是否存在 API 应该只获取参数作为 std::weak_ptr 而不是 std::shared_ptr 的参数？
p.s。有，但总体上没有明确回答我的问题。
如果 API 方法需要很长时间执行，那么 shared_ptr 将在执行期间被锁定，如果它花费 std::shared_ptr 而不是 std::weak_ptr.在不知道 API.
的情况下很难判断这是否是一个问题
我认为这种方法没有任何真正的缺点，从 shared_ptr 转换为 weak_ptr 并再次返回 shared_ptr 的成本很小，当然也很复杂就实现而言，成本虽然可能必须检查空指针，但成本可能很小。
我倾向于遵循的规则是：如果被调用者没有处理 lifetime/ownership，则不要将智能指针传递给它；相反，传入原始 C++ 引用（首选）或原始指针。我发现将所有权问题与使用问题分开更加清晰和灵活。
[注：这也是我对另一个问题的回答：what's the point of std::unique_ptr::get
我正在使用 C++ 库的 API，它需要大量 std::weak_ptr 作为 API 方法的输入参数。库 不保留 这些指针，只是对它们进行一些处理。对我来说，从图书馆的角度来看，这个设计是这样的：
Hi API User,
You have passed me some weak pointers as the input parameter(s) of a method to get a service from the library. But your pointers may be expired and not valid anymore. OK, no problem, I will do the check and let you know about it.
BR, Library API
这样一个API的设计，用一个std::shared_ptr获取所有的指针不是更合理吗？在这种情况下，如果 API 用户正在使用 weak_ptrs，则用户有责任首先 .lock() weak_ptr 指针，然后将它们传递给 API（如果 .lock() 成功）。是否存在 API 应该只获取参数作为 std::weak_ptr 而不是 std::shared_ptr 的参数？
p.s。有
如果 API 方法需要很长时间执行，那么 shared_ptr 将在执行期间被锁定，如果它花费 std::shared_ptr 而不是 std::weak_ptr.在不知道 API.
我认为这种方法没有任何真正的缺点，从 shared_ptr 转换为 weak_ptr 并再次返回 shared_ptr 的成本很小，当然也很复杂就实现而言，成本虽然可能必须检查空指针，但成本可能很小。
我倾向于遵循的规则是：如果被调用者没有处理 lifetime/ownership，则不要将智能指针传递给它；相反，传入原始 C++ 引用（首选）或原始指针。我发现将所有权问题与使用问题分开更加清晰和灵活。
[注：这也是我对另一个问题的回答：what's the point of std::unique_ptr::get