The *_s
functions are Microsoft's attempt at being clever and "securing" the C runtime library's string functions. The functions even made it into C99's Appendix K. They are not implemented in Linux' glibc at the time of this writing. If you absolutely must (and I advise against it), just use the normal C library functions correctly (this means no magic numbers and proper buffer sizes everywhere), and yes, this is a pain in the bum.
This might or might not be usable within the context of your assignment, but it is really the only correct answer:
class PhoneNumber
{
private:
std::string name;
// ...
public:
void setName(std::string name);
//...
};
void PhoneNumber::setName(std::string name)
{
this->name = std::move(name); // 'this->' is optional, but clarifies without resorting to some clever renaming of the variables
}
Alternatively, drop the setter altogether:
struct PhoneNumber
{
std::string name;
// ...
};
and assign the member directly. But this style of coding, although perfectly sane, might get you yelled at by your teacher.
Don't use C char arrays in C++. You'll shoot yourself in the foot for no good reason. It also gets rid of the magic number in your code, which is always a plus.
Tiny C++11 and later template wankery. The ideal solution of implementing the setter is using templates, so that a potential costly double-move can be prevented if the setter is called like setName(std::move(some_string))
:
template<typename T>
void setName(T&& name) { this->name = std::forward<T>(name); }
This will allow anything that is assignable/moveable to a std::string to be accepted, which is actually quite nice all in all. As an added benefit, you get the best possible code path selected for you automagically. Of course for your assignment this will be huge overkill, but if you take the time to learn about these concepts you might just teach the teacher something. Again, prefer a public
member to this template ... wankery, because that is what this is.