原始指针获取程序的C ++ 11 const正确性

Question

I've come across a small issue with const correctness in C++11 which I was hoping I could get clarified--I don't think it has already been asked!

Assume we have a class A, which contains an instance of class B which we want to expose. If we exposed it as a reference we would provide both const and non-const versions of the getter:

class B;

class A final
{
public:
    B& GetB() 
    {
        return m_b;
    }
    const B& GetB() const 
    {
        return m_b;
    }
private:
    B m_b;
};

However if we just had a pointer to B we would provide a getter which was const but returned a copy of the pointer to a non-const instance of B. This is because A doesn't OWN B, it only owns the the pointer, and therefore external modification of B doesn't change the state of A. (Note: I've come to this conclusion from personal experience; I've never found anything explicitly stating this is how this should work)

class B;

class A final
{
public:
    A(B* b) 
    {
        m_b = b;
    }
    A* GetB() const
    {
        return m_b;
    }
private:
    B* m_b;
};

This all makes sense so far, but what do we do if A owns a unique pointer (or shared pointer for that matter) to B? A now logically owns B--even if not literally. Up until now I've been following the second example above when exposing a raw pointer to a shared pointer, but since A logically owns B should I be doing something more similar to the first example?

class B;

class A final
{
public:
    A(std::unique_ptr<B> b)
    {
        m_b = std::move(b);
    }
    B* GetB()
    {
        return m_b.get();
    }
    const B* GetB() const
    {
        return m_b.get();
    }
private:
    std::unique_ptr<B> m_b;
};

Answer 1

In this case, if your design was correct when A held a B by value, then I'd use the same const/non-const accessors for the case when A holds a B by std::unique_ptr .

Why? Barring some additional means of ownership transfer away from A (such as a move assignment operator), in both cases A owns a B that will live and die with it. That in the latter case the B instance happened to have been allocated separately on the heap and provided to the constructor is immaterial; its lifetime is the same.

There's yet another variation of your example that may help settle your vacillation, assuming that we don't need to deal with the possibility of A::m_b being null:

class B
{
  // ...
};

class A final
{
public:
  A() : m_b(std::make_unique<B>())
  {}

  B& GetB()
  {
    return *m_b;
  }

  const B& GetB() const
  {
    return *m_b;
  }

private:
  std::unique_ptr<B> m_b;
};

Here, A clearly owns its B , and offers no way to transfer ownership. I don't know why we'd allocate B on the heap here, but we can just to make a point. (Note that now A::GetB() returns by reference rather than pointer.) With this example, would you still have a hard time deciding how to write A::GetB() and whether to overload it on const?

Answer 2

While I do not have much authority to answer design questions, I would use something akin to has been proposed in @seh's answer , with the addition of a way to check for the null value of m_b :

class B
{
  // ...
};

class A final
{
public:
  A(std::ptr<B> b) : m_b(std::move(b))
  {}

  bool HasB()
  {
    return m_b != nullptr;
  }

  B& GetB()
  {
    return *m_b;
  }

  const B& GetB() const
  {
    return *m_b;
  }

 private:
   std::unique_ptr<B> m_b;
};

If you really can't do without pointers (legacy API), then it is more of a grey line. I would declare both const B* GetB() const and B* GetB() , since a common convention in C++11 is that raw pointers can be used to represent non-owning pointers . Ultimately this would have to been indicated in documentation, though.

Answer 3

For an ownership situation it would IMHO be unnatural if a member function could allow modification of a part of a logically const object, but that's a design issue.

However, do note that a raw pointer can be used to implement ownership.

For example, consider an internal array implemented with direct new -ing and raw pointer. You would not want an interface that would break when/if that was replaced with a std::vector for handling the storage. And so the rule for whether to provide a const /non- const pair of accessor functions must be rooted in the design level, not in what the language permits for a given implementation of the design.