3

私は C++ にはかなり慣れていませんが (C や OOP ではありません)、物事を「正しい」方法で行い、悪い習慣や危険な習慣を避けようとしているので、Google の C++ コーディング ガイドラインと効果的な C++ を次のように使用しています。私の学びの出発点。

unique_ptrメンバーとして aを持つ抽象基本クラスがあります。非公開にし、getter を介して派生クラスへのアクセスのみを提供する場合 (Google C++ スタイル ガイドラインに従って)、これが最善の方法ですか? それとも、ここで潜在的な落とし穴を見逃していますか?

Base.h:

#include "Document.h"

typedef std::unique_ptr<Document> pDOC;

class Base {
public:
    Base();
    virtual ~Base() = 0;

    pDOC& GetDoc();

private:
    // Unique pointers cannot be shared, so don't allow copying
    Base(Base const &); // not supported
    Base &operator=(Base const &); // not supported
    pDOC m_doc;
};

Base.cpp

#include "base.h"

Base::Base()
: m_xmldoc(new Document) {}

// Class destructor (no need to delete m_doc since it is a smart pointer)
Base::~Base() {}

pDOC& Base::GetDoc() {
    return m_doc;
}
4

3 に答える 3

4

まず、 --upDocの代わりに呼び出して、型が単なるポインタではないことを示す必要があるほど奇妙です。(ポインター型を小文字の p で始まるものとして定義する傾向が強いため、多くの人が混乱する可能性があります)。pDOCunique_ptr

第二に、GetDoc派生クラスのみを対象とする場合はprotected、public.

unique_ptr3 番目に、への参照をすべての子に完全に公開することに疑問があります。の責任はBase？の寿命を管理しm_docますか? もしそうならDocument*、upDoc（return m_doc.get();の代わりにreturn m_doc;）の代わりに

ライフタイムを管理せずにすべてBaseが保持されている場合m_doc、なぜそれが存在するのでしょうか? パブリック インターフェイスを提供せず、ほとんどまたはまったく機能を提供しません。

于 2013-01-16T16:44:25.103 に答える
0

プライベートにして、ゲッターを介して派生クラスへのアクセスのみを提供する場合

次に、パブリック/保護されたメンバーを直接提供するのと同じ効果を得るために、追加の入力を行っています。確かに、アクセサーにコードを追加したり、ブレークポイントを設定したりできますが、内部への直接アクセスを提供することでカプセル化を解除しているという事実は変わりません。

obj.GetDoc().release()別の言い方をすれば、そのタイプのユーザーがあなたのタイプの不変条件を実行したり破ったりするのを妨げるものは何もありません。

于 2013-01-16T17:06:58.280 に答える
0

もう 1 つの方法は、 によって管理されるオブジェクトへの参照を公開することstd::unique_ptrです。次に例を示します。

    const Document& getDocument() const { return *m_doc; }
    Document& getMutableDocument() { return *m_doc; }

これは、Jonas Devlieghere によって、「一意のポインターのコンテナー」を公開するための可能なアプローチとしてここで提案されています。 object] の寿命。 "

于 2019-05-14T15:05:49.893 に答える