Is modifying data passed by const shared_ptr& Ok? - c++

Question

I've come across a situation where I needed to set a property to a library object by means of a setter accepting const shared_ptr reference. Here is a simple example:
// library class
class WidgetProxy {
public:
void setName(const std::shared_ptr<std::string>& name);
// more methods
};
Suspecting nothing, I used it like this:
WidgetProxy widgetProxy(...);
auto name = std::make_shared<std::string>("Turing");
widgetProxy.setName(name);
// continue using `name`
Then I've found out that name had become empty after setName() call. Luckily, library source code was available and I was able to examine the implementation. It was roughly the following:
class WidgetImpl {
public:
void setName(std::string name)
{
name_ = std::move(name);
}
private:
std::string name_;
};
void WidgetProxy::setName(const std::shared_ptr<std::string>& name)
{
widgetImpl_.setName(std::move(*name));
}
So setName() moves out the string wrapped by the shared_ptr which is formally not prohibited since shared_ptr template argument is std::string and not const std::string.
My questions:
Is it a normal design to implement WidgetProxy::setName() like this?
Should a library user normally expect such behavior when they see a const shared_ptr<T>& function parameter?
Upd: The posted code snippets are much simplified. In the library there is a different type in place of std::string. I have also omitted checks for pointer validity.

Answer 1

Is it a normal design to implement setName() like this?
This implementation style is OK:
void setName(std::string name)
{
name_ = std::move(name);
}
The string is first copied by the function call, and the copied string is moved to the class member. The resulting code is as efficient than passing a reference to a string, and then copying to the data member.
This one is not. And I do not not recommend it.
void WidgetProxy::setName(const std::shared_ptr<std::string>& name)
{
widgetImpl_.setName(std::move(*name));
}
For 2 reasons. 1: why require a std::shared_ptr if the pointer is not kept? 2: The net result of the operation deletes the string held by the pointee. This affects all the other holders of the shared_ptr, some of which may need the value of the original string.
A more correct way to write this function, and the associated function call:
void WidgetProxy::setName(std::string name)
{
widgetImpl_.setName(std::move(name));
}
// call as:
if (strPtr)
proxy.setName(*strPtr); // with strPtr being a std::shared_ptr<std::string>
Should a library user normally expect such behavior when they see a const shared_ptr& function parameter?
No. This is a terrible way of coding a library. If the caller wishes to keep the string for any reason, he must create a shared_ptr with a copy of the original string. Plus, the library code does not even check if the shared_ptr holds a valid pointer! Very, very naughty.

Answer 2

You misunderstand what this means:
class WidgetProxy {
public:
void setName(const std::shared_ptr<std::string>& name);
};
setName takes a reference to a possibly mutable shared pointer that it does not have permission to modify. This shared pointer refers to a mutable string.
This means within setName, whenever control flows out of what is visible to the compiler, the pointer and validity of name could change (and, you should check that it does not).
The value pointed to by this non-mutable view of a possibly mutable shared pointer is fully mutable. You have full permission to modify it.
Some alternatives:
class WidgetProxy {
public:
void setName(std::shared_ptr<std::string> name);
};
This is a local shared pointer to a mutable string. It can only be modified locally, unless you leak references to it. The data referred to be be manipulated by any other code, and must be assumed to be modified whenever local context is left. It will, however, remain a valid pointer over the lifetime of the setName function unless you personally clear it.
class WidgetProxy {
public:
void setName(std::shared_ptr<std::string const> name);
};
this is a local shared pointer to a string you do not have mutation rights to. Someone else with a shared pointer to it could modify it if it is actually mutable at any point you leave local code, and should be presumed to be doing so.
class WidgetProxy {
public:
void setName(std::string name);
};
this is a local copy of a buffer of characters that nobody else can modify within the function, and that you own.
class WidgetProxy {
public:
void setName(std::string const& name);
};
this is a reference to a possibly mutable external std::string which must be presumed to be changed every time you leave local code in the function.
Personally, I see no reason why WidgetProxy is taking an arguments by shared_ptr or const&. It doesn't use the shared-ness of the argument, nor does it want the value to be remotely changed on it. It is a "sink" argument that it will consume, and the cost of moving the object is low.
WidgetProxy::setName should take a std::string. Sink arguments of cheap-to-move data should take by-value. And use of smart pointers here seems like a horrid idea; why complicate your life with shared_ptr?

Answer 3

It is perfectly fine for WidgetImpl::setName() to be implemented in this manner, as it is moving from local parameter.
It is simply a bug to implement WidgetProxy::setName this way, because you can't realistically expect the object managed by shared_ptr to be movable.