Should a std::string class member be a pointer?

Question

And why/why not?

Say I have a class which takes a string in the constructor and stores it. Should this class member be a pointer, or just a value?

class X {
    X(const std::string& s): s(s) {}
    const std::string s;
};

Or...

class X {
    X(const std::string* s): s(s) {}
    const std::string* s;
};

If I was storing a primitive type, I'd take a copy. If I was storing an object, I'd use a pointer.

I feel like I want to copy that string, but I don't know when to decide that. Should I copy vectors? Sets? Maps? Entire JSON files...?

EDIT:

Sounds like I need to read up on move semantics. But regardless, I'd like to make my question a little more specific:

If I have a 10 megabyte file as a const string, I really don't want to copy that.

If I'm newing up 100 objects, passing a 5 character const string into each one's constructor, none of them ought to have ownership. Probably just take a copy of the string.

So (assuming I'm not completely wrong) it's obvious what to do from outside the class, but when you're designing class GenericTextHaver, how do you decide the method of text-having?

If all you need is a class that takes a const string in its constructor, and allows you to get a const string with the same value out of it, how do you decide how to represent it internally?

Answer 1

Should a std::string class member be a pointer?

No

And why not?

Because std::string, like every other object in the standard library, and every other well-written object in c++ is designed to be treated as a value.

It may or may not use pointers internally - that is not your concern. All you need to know is that it's beautifully written and behaves extremely efficiently (actually more efficient than you can probably imagine right now) when treated like a value... particularly if you use move-construction.

I feel like I want to copy that string, but I don't know when to decide that. Should I copy vectors? Sets? Maps? Entire JSON files...?

Yes. A well-written class has "value semantics" (this means it's designed to be treated like a value) - therefore copied and moved.

Once upon a time, when I was first writing code, pointers were often the most efficient way to get a computer to do something quickly. These days, with memory caches, pipelines and prefetching, copying is almost always faster. (yes, really!)

In a multi-processor environment, copying is very much faster in all but the most extreme cases.

If I have a 10 megabyte file as a const string, I really don't want to copy that.

If you need a copy of it, then copy it. If you really just mean to move it, then std::move it.

If I'm newing up 100 objects, passing a 5 character const string into each one's constructor, none of them ought to have ownership. Probably just take a copy of the string.

A 5-character string is so cheap to copy that you should not even think about it. Just copy it. Believe it or not, std::string is written with the full knowledge that most strings are short, and they're often copied. There won't even be any memory allocation involved.

So (assuming I'm not completely wrong) it's obvious what to do from outside the class, but when you're designing class GenericTextHaver, how do you decide the method of text-having?

Express the code in the most elegant way you can that succinctly conveys your intent. Let the compiler make decisions about how the machine code will look - that it's job. Hundreds of thousands of people have given their time to ensure that it does that job better than you ever will.

If all you need is a class that takes a const string in its constructor, and allows you to get a const string with the same value out of it, how do you decide how to represent it internally?

In almost all cases, store a copy. If 2 instances actually need to share the same string then consider something else, like a std::shared_ptr. But in that case, they probably would not only need to share a string so the 'shared state' should be encapsulated in some other object (ideally with value semantics!)

OK, stop talking - show me how the class should look

class X {
public:

    // either like this - take a copy and move into place
    X(std::string s) : s(std::move(s)) {}

   // or like this - which gives a *miniscule* performance improvement in a
   // few corner cases
/*
   X(const std::string& s) : s(s) {}  // from a const ref
   X(std::string&& s) : s(std::move(s)) {}  // from an r-value reference
*/

  // ok - you made _s const, so this whole class is now not assignable
  const std::string s;

  // another way is to have a private member and a const accessor
  // you will then be able to assign an X to another X if you wish

/*    
  const std::string& value() const {
    return s;
  }

private:
  std::string s;
*/
};