returning reference from class

Hello
I have a simple question.

Suppose I have:

Code:

---

class someclass {
public:
  int &number() const { return m_number; } //this is okay
  std::string &str() const { return m_str; } //this aint okay
private:
  int m_number;
  std::string m_str;
};

---

How do you professionals return string by reference this way (const - so that it cannot be modified inside the function)?

Should I just do:

Code:

---

std::string &str() { return m_str; }

---

instead?

Thanks for help!

If you don't want the string modified, then you could do:

Code:

---


const std::string &str() const { return m_str; }

---

You probably shouldn't allow outside functions to modify the string anyways.

--
Mats

Either

Code:

---

const std::string &str() const { return m_str; }

---

or

Code:

---

std::string &str() const { return m_str; }

---

Will give error: cannot convert from 'const std::string' to 'std::string &'

What makes returning a non-const int reference ok, but a non-const string reference not?

Anyway, I never return references from my getters, except in very special circumstances. Certainly not for value-like objects like string. It loses half the advantage of a getter. You can no longer change the underlying member's type.

Quote:

---

Originally Posted by CornedBee

Anyway, I never return references from my getters, except in very special circumstances. Certainly not for value-like objects like string. It loses half the advantage of a getter.

---

So you recomment me to return just values in this case? What kind of advantage it loses?

The advantage it loses was in my last sentence.

What does losing ability to change the underlying member's type mean?
Can show an example please?

It means that, if you later on, decide to change from a std::string to nonstd::gnirts, which does the same thing as std::string, but uses a different internal format [and thus is much better for what you use it for most of the time], you can't do that without also changing all the code that calls str() in your class - but if you "hide" the fact that the internal structure is a string [just deliver a copy of the string, rather than a reference], then the code calling str() won't have to change if you modify the underlying form of m_str.

--
Mats

Quote:

---

Originally Posted by l2u

Either

Code:

---

const std::string &str() const { return m_str; }

---

or

Code:

---

std::string &str() const { return m_str; }

---

Will give error: cannot convert from 'const std::string' to 'std::string &'

---

Well, sure. Inside a const function, all member variables act like they are const. So you can't return a non-const reference to a member from inside a const function. I don't believe you that the first example doesn't work. It should work fine.

Quote:

---

Originally Posted by brewbuck

Well, sure. Inside a const function, all member variables act like they are const. So you can't return a non-const reference to a member from inside a const function. I don't believe you that the first example doesn't work. It should work fine.

---

It does.. Sorry, I missed something :)

Quote:

---

Originally Posted by matsp

It means that, if you later on, decide to change from a std::string to nonstd::gnirts, which does the same thing as std::string, but uses a different internal format [and thus is much better for what you use it for most of the time], you can't do that without also changing all the code that calls str() in your class - but if you "hide" the fact that the internal structure is a string [just deliver a copy of the string, rather than a reference], then the code calling str() won't have to change if you modify the underlying form of m_str.

--
Mats

---

I've always used reference because I thought only about the preformance..
So you all agree that its generally better to avoid returning references to strings?

It's better to avoid returning references to private members. That they're strings is irrelevant.

Don't return references to member variables. It doesn't matter if they are strings, array, structs or simple variables.

If the compiler is clever, and you inline the function, it may skip the copying when there's no possibility of the data being abused. It does assume the compiler "understands" what's going on [const correctness helps here].

--
Mats

If I just return string by value I guess I shouldnt return const string? Is that right?

You can, but you don't need to.

Code:

---

const std::string Help2()
{
        return "";
}

void Help()
{
        std::string s = Help2();
}

---

Visual Studio completely ignores the const there since it's a return-by-value. The Help function can use it however much it wants, but it cannot actually modify the original string that's returned (since it's return-by-value).

Following also works:

Code:

---

const std::string& Help2()
{
        static std::string s = "";
        return s;
}

void Help()
{
        std::string s = Help2();
}

---

Following does not work:

Code:

---

const std::string& Help2()
{
        static std::string s = "";
        return s;
}

void Help()
{
        std::string& s = Help2(); // Add const and it will compile
}

---

Don't return by const value. At best, it does nothing. At worst, it confuses the optimizer.

And do not return reference to static local var from function that may be used in multithreading envirounment

Avoid returning any static local var, I say. If so, create them on the heap.
That's my opinion, though. Though the example illustrates the purpose in the simplest of ways.