I understand that std::unique_ptr
is the way it is and probably won't be changed to break backwards compatibility but I was wondering if anyone has a good reason why the writers of the spec didn't overload the get
method with a const variant that looks like
const T* get() const;
to follow the intent of the unique_ptr
being const
.
My best guess is that it is trying to mirror pointers and act like a T* const
instead of a typical class. As a follow-up question, if I wanted to hold a pointer in a const-like fashion in a const instance of my class, should I be using something else other than std::unique_ptr
to hold the data?
Update
In my case I want to protect myself from misusing the pointer in the class itself. I was writing a const move constructor MyClass(const MyClass&& other)
and was copying the data from the new instance into other via std::copy
. It took a long time to track down the bug because I had assumed the copy must be correct because of const protection. I'm trying to figure out what I could have done to protect myself from this outside of providing a const getter and using that within the class when doing the copy.
std::unique_ptr<YourClass const>
do what you seek? Or did I misunderstand that part of the question. – WhozCraigchar[]
and anint
to represent the length. I want to pass it around and let consumers manipulate the bytes unless they have a const instance. Even if I provide const and non-const getters for the data, I want to ensure my internal methods don't mess with data on a const instance passed in to a method on my class – quittle