-3

Is there any issue in the following code? I am told it's there, but I couldn't find it...

std::string fun(int i)
{
    std::ostringstream t;
    t<<"My int is "<<i<<returnSomething();
return t.str();
}
George Nel
  • 1
  • 1
  • Assuming the proper include files, it seems just fine. The function is returning the string by value, and thus avoids some potential problems. – Bo Persson Jun 19 '12 at 15:13
  • 3
    We lack some information to answer. What kind of issue ? Who told you that ? What is the expected behavior and what do you observe ? – ereOn Jun 19 '12 at 15:14
  • There is lacking information to tackle the specific concerns, but there is more than enough information to actualy *answer* whether the code is safe or not. It contains a precise small test case and a concrete question. Admittedly, providing the concern would allow to address it more precisely... – David Rodríguez - dribeas Jun 19 '12 at 15:28

1 Answers1

3

The code in the question is fine. It would be a problem if you returned a pointer into the local object (say that you returned a const char* obtained as t.str().c_str()) or if you returned a reference. But in your code, a copy of the internal string in the std::ostringstream is performed before the function completes (as part of the return statement), and before t gets destroyed, so it is fine.

David Rodríguez - dribeas
  • 204,818
  • 23
  • 294
  • 489
  • sorry, i edited it now...there's a call to a function... – George Nel Jun 19 '12 at 15:41
  • Clue I was given is: it's related to internalization... – George Nel Jun 19 '12 at 15:49
  • @GeorgeNel There's no such thing as internalization in C++ (unless you implement it in a class you write). – James Kanze Jun 19 '12 at 15:57
  • @JamesKanze Can you please explain the part `unless you implement ...` ? – George Nel Jun 19 '12 at 16:06
  • @GeorgeNel: The answer still applies. Assuming that `returnSomething()` is well behaved (i.e. it does not cause undefined behavior by itself), the return value (possible temporary) will be inserted into the stream while it is still alive, and there is no difference from the argument above. What is *your concern*? It seems that if you explain where you see the problem it would be easier to explain why it is not (or it is) an issue. – David Rodríguez - dribeas Jun 19 '12 at 16:12
  • Does it make a difference if an object is printed into the stream? like `t< – George Nel Jun 19 '12 at 16:14
  • A friend of mine told this & I am trying to figure out before going back & asking him eventually...There's no bigger picture to the problem other the specified one... – George Nel Jun 19 '12 at 16:16
  • @GeorgeNel Just what I said. Unless you implement some sort of internalization in a class of your own, there isn't any in C++. – James Kanze Jun 19 '12 at 17:52
  • I have a question about interpreting the second sentence ("It would be,,,"). It is my understanding that since `str` produces a copied `std::string` (which is why this example is OK), while `c_str` returns a pointer to the internal character array of the `std::string`, any use of `t.str().c_str()` is dead on arrival: the `char*` is returned, then the temporary `std::string` is destructed, and your pointer is dangling even if the `std::ostringstream` is still alive. So that would be problematic even without trying to return the pointer from `fun`. Is that right? – Marc van Leeuwen Dec 29 '20 at 14:59