我有一个继承自enable_shared_from_this的类。它有shared_ptr个子对象，并且有一个“根”对象，因此整个层次结构由shared_ptr管理。这样一个对象可以有多个父对象并被安全地破坏。
我开始编写构造函数，然后我意识到用户应该像我在内部使用std::shared_ptr来管理对象，就像我在一些现有的库中看到的那样，例如gtkmm。所以我可以做我看到别人做的事情：隐藏构造函数，并编写一个静态成员函数create（），它返回一个shared_ptr到新对象。显然，create（）非常有用，因为没有它我需要调用std::make_shared()或稍后调用std::shared_from_this()。
但我应该隐藏构造函数，为什么？我可以猜出一些很好的理由，例如它强制用户使用shared_ptr，否则对象会被删除，因此可以保证用户不使用不受shared_ptr管理的“孤儿”对象。并且它确保用户不会忘记手动创建shared_ptr，因为遗忘意味着对象被删除，即使它被复制（深拷贝，而不是指针的副本），然后用户会非常快速地注意到。 / p>
另一个有趣的选择是没有create（）静态方法，而是将add_child（）方法作为创建新对象的唯一方法。这可以保证它与层次结构相关联。问题：灵活性。如果有人想单独使用某个对象，那么除非你派出这个类，否则这是不可能的。
你会做什么/我应该做什么？隐藏/不隐藏ctor？ add_child()？ create()？
答案 0 :(得分：1)
在一般情况下，没有一个正确答案。您可以从编写所有这些方法开始：constructor，create（）和create_child（），全部公开。然后，在使用界面时，最好在测试时（如果可能的话，在“真实”代码中使用它之前完成它），检查可能的副作用，结果和不同构造选项的便利性，并确定什么是对于您的特定用例，最好的，安全的。
如果一切都安全的话，你可以把所有三个公开。否则，通过将它们设为私有（或者可能是受保护的，如果它是要派生的类的构造函数）来隐藏不安全的那些，并将安全的公开给用户使用。