Is it safe to use c_str() on a temporary string? The Next CEO of Stack OverflowIs a string literal in c++ created in static memory?string and const char* and .c_str()?What is the difference between String and string in C#?How do I iterate over the words of a string?How do I read / convert an InputStream into a String in Java?Case insensitive 'Contains(string)'How do I make the first letter of a string uppercase in JavaScript?How to replace all occurrences of a string in JavaScriptHow to check whether a string contains a substring in JavaScript?Does Python have a string 'contains' substring method?How do I convert a String to an int in Java?Why is char[] preferred over String for passwords?
Which organization defines CJK Unified Ideographs?
Term for the "extreme-extension" version of a straw man fallacy?
Why do professional authors make "consistency" mistakes? And how to avoid them?
Opposite of a diet
Can I equip Skullclamp on a creature I am sacrificing?
What is the difference between "behavior" and "behaviour"?
How do I solve this limit?
How to write the block matrix in LaTex?
Is it my responsibility to learn a new technology in my own time my employer wants to implement?
Trouble understanding the speech of overseas colleagues
Does the Brexit deal have to be agreed by both Houses?
Would this house-rule that treats advantage as a +1 to the roll instead (and disadvantage as -1) and allows them to stack be balanced?
How to count occurrences of text in a file?
When Does an Atlas Uniquely Define a Manifold?
Implement the Thanos sorting algorithm
What happens if you roll doubles 3 times then land on "Go to jail?"
What's the point of interval inversion?
India just shot down a satellite from the ground. At what altitude range is the resulting debris field?
Can a single photon have an energy density?
Where to find order of arguments for default functions
WOW air has ceased operation, can I get my tickets refunded?
Grabbing quick drinks
I believe this to be a fraud - hired, then asked to cash check and send cash as Bitcoin
When airplanes disconnect from a tanker during air to air refueling, why do they bank so sharply to the right?
Is it safe to use c_str() on a temporary string?
The Next CEO of Stack OverflowIs a string literal in c++ created in static memory?string and const char* and .c_str()?What is the difference between String and string in C#?How do I iterate over the words of a string?How do I read / convert an InputStream into a String in Java?Case insensitive 'Contains(string)'How do I make the first letter of a string uppercase in JavaScript?How to replace all occurrences of a string in JavaScriptHow to check whether a string contains a substring in JavaScript?Does Python have a string 'contains' substring method?How do I convert a String to an int in Java?Why is char[] preferred over String for passwords?
#include <iostream>
std::string get_data()
return "Hello";
int main()
const char* data = get_data().c_str();
std::cout << data << "n";
return 0;
"Hello" is printing on my machine; however, I am led to believe that this behavior is unspecified i.e. implementation-specific. Am I correct or will it always print "Hello", judging that the returned string is immutable and as such qualified as something that is constant?
c++ string object-lifetime
New contributor
|
show 5 more comments
#include <iostream>
std::string get_data()
return "Hello";
int main()
const char* data = get_data().c_str();
std::cout << data << "n";
return 0;
"Hello" is printing on my machine; however, I am led to believe that this behavior is unspecified i.e. implementation-specific. Am I correct or will it always print "Hello", judging that the returned string is immutable and as such qualified as something that is constant?
c++ string object-lifetime
New contributor
1
Where does that string that gets returned go afterc_str()
is called and returns a pointer to some data?
– tadman
6 hours ago
2
stackoverflow.com/questions/23464504/…
– Wyck
6 hours ago
2
Probably not a duplicate but helpful: stackoverflow.com/questions/349025/…. Also your interview question is missing#include <string>
so technically it would be a compiler error ;)
– Tas
6 hours ago
1
I'm a bit surprised that the documentation forstd::string::c_str
doesn't mention destruction of the string as grounds for the returned pointer being invalidated (unless you consider the destructor to be a non-const member function). I think many people coming from a C background would benefit from having this written explicitly
– alter igel
5 hours ago
1
@Tas: io-streams implement the shift-operators including overloads on basic_string ,so it needs its definition which requires it to include <string>. So it can't be a compiler error.
– engf-010
5 hours ago
|
show 5 more comments
#include <iostream>
std::string get_data()
return "Hello";
int main()
const char* data = get_data().c_str();
std::cout << data << "n";
return 0;
"Hello" is printing on my machine; however, I am led to believe that this behavior is unspecified i.e. implementation-specific. Am I correct or will it always print "Hello", judging that the returned string is immutable and as such qualified as something that is constant?
c++ string object-lifetime
New contributor
#include <iostream>
std::string get_data()
return "Hello";
int main()
const char* data = get_data().c_str();
std::cout << data << "n";
return 0;
"Hello" is printing on my machine; however, I am led to believe that this behavior is unspecified i.e. implementation-specific. Am I correct or will it always print "Hello", judging that the returned string is immutable and as such qualified as something that is constant?
c++ string object-lifetime
c++ string object-lifetime
New contributor
New contributor
edited 2 hours ago
Hong Ooi
43.1k1097139
43.1k1097139
New contributor
asked 6 hours ago
Aknin AbdoAknin Abdo
491
491
New contributor
New contributor
1
Where does that string that gets returned go afterc_str()
is called and returns a pointer to some data?
– tadman
6 hours ago
2
stackoverflow.com/questions/23464504/…
– Wyck
6 hours ago
2
Probably not a duplicate but helpful: stackoverflow.com/questions/349025/…. Also your interview question is missing#include <string>
so technically it would be a compiler error ;)
– Tas
6 hours ago
1
I'm a bit surprised that the documentation forstd::string::c_str
doesn't mention destruction of the string as grounds for the returned pointer being invalidated (unless you consider the destructor to be a non-const member function). I think many people coming from a C background would benefit from having this written explicitly
– alter igel
5 hours ago
1
@Tas: io-streams implement the shift-operators including overloads on basic_string ,so it needs its definition which requires it to include <string>. So it can't be a compiler error.
– engf-010
5 hours ago
|
show 5 more comments
1
Where does that string that gets returned go afterc_str()
is called and returns a pointer to some data?
– tadman
6 hours ago
2
stackoverflow.com/questions/23464504/…
– Wyck
6 hours ago
2
Probably not a duplicate but helpful: stackoverflow.com/questions/349025/…. Also your interview question is missing#include <string>
so technically it would be a compiler error ;)
– Tas
6 hours ago
1
I'm a bit surprised that the documentation forstd::string::c_str
doesn't mention destruction of the string as grounds for the returned pointer being invalidated (unless you consider the destructor to be a non-const member function). I think many people coming from a C background would benefit from having this written explicitly
– alter igel
5 hours ago
1
@Tas: io-streams implement the shift-operators including overloads on basic_string ,so it needs its definition which requires it to include <string>. So it can't be a compiler error.
– engf-010
5 hours ago
1
1
Where does that string that gets returned go after
c_str()
is called and returns a pointer to some data?– tadman
6 hours ago
Where does that string that gets returned go after
c_str()
is called and returns a pointer to some data?– tadman
6 hours ago
2
2
stackoverflow.com/questions/23464504/…
– Wyck
6 hours ago
stackoverflow.com/questions/23464504/…
– Wyck
6 hours ago
2
2
Probably not a duplicate but helpful: stackoverflow.com/questions/349025/…. Also your interview question is missing
#include <string>
so technically it would be a compiler error ;)– Tas
6 hours ago
Probably not a duplicate but helpful: stackoverflow.com/questions/349025/…. Also your interview question is missing
#include <string>
so technically it would be a compiler error ;)– Tas
6 hours ago
1
1
I'm a bit surprised that the documentation for
std::string::c_str
doesn't mention destruction of the string as grounds for the returned pointer being invalidated (unless you consider the destructor to be a non-const member function). I think many people coming from a C background would benefit from having this written explicitly– alter igel
5 hours ago
I'm a bit surprised that the documentation for
std::string::c_str
doesn't mention destruction of the string as grounds for the returned pointer being invalidated (unless you consider the destructor to be a non-const member function). I think many people coming from a C background would benefit from having this written explicitly– alter igel
5 hours ago
1
1
@Tas: io-streams implement the shift-operators including overloads on basic_string ,so it needs its definition which requires it to include <string>. So it can't be a compiler error.
– engf-010
5 hours ago
@Tas: io-streams implement the shift-operators including overloads on basic_string ,so it needs its definition which requires it to include <string>. So it can't be a compiler error.
– engf-010
5 hours ago
|
show 5 more comments
2 Answers
2
active
oldest
votes
The code exhibits undefined behavior.
get_data()
returns a temporary which expires at the end of the full expression (*):
const char* data = get_data().c_str() ;
// ^~~~~~~~~~ ^
// this evaluates |
// to a prvalue |
// temporary expires here
data
points to an internal of that object, so after the temporary ends you are left with a dangling pointer. Accessing it leads to Undefined Behavior. So the next line std::cout << data << "n";
makes the whole program exhibit Undefined Behavior.
*) There is an exception to this rule which doesn't apply here. If a prvalue is directly bound to a reference, the lifetime of the prvalue is extended to the lifetime of the reference.
For instance, this would have been fine:
int main()
const std::string& ref = get_data();
const char* data = ref.c_str();
std::cout << data << "n";
return 0;
Your answer should include something with the words sequence point to get my upvote, because people still search for that - even though it doesn't appear in the standard.
– Wyck
5 hours ago
1
@Wyck I don't see how sequence points are relevant here. The only thing that matters is the lifetime of the temporary. And that lifetime is until the end of the full expression it appears on.
– bolov
5 hours ago
1
@Wyck newer standards don't use "sequence points" indeed. They use "sequenced after" and "sequenced before". I still don't see the connection to the problem at hand... Maybe I am missing something, could you please tell how sequencing relates here?
– bolov
5 hours ago
1
@Wyck a single statement can possibly have multiple sequencing considerations, but they would not affect when a temporary is destroyed
– kmdreko
5 hours ago
1
The only thing that this doesn't cover is the Asker's statement that judging that the returned string is immutable suggests that they might not know that the string literal and the returnedstd::string
are separate objects.
– user4581301
5 hours ago
|
show 2 more comments
Yes it is, but not the way you're doing it.
If you did this:
std::cout << get_data().c_str() << 'n';
you'd be just fine.
That's because a temporary is guaranteed to live for the lifetime of the full expression it was created in. It may live longer in certain, very specific circumstances.
If you bind a const reference to a temporary, it's lifetime will be extended to be the lifetime of the name it was bound to. So, code like this:
std::string const &x = get_data();
std::cout << x.c_str() << 'n';
would also work because the temporary returned by get_data
would be bound to the reference named x
, and so as long as x
remained a valid name to use, the temporary would still exist.
1
A const reference, I think you mean.
– Nemo
2 hours ago
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Aknin Abdo is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55408411%2fis-it-safe-to-use-c-str-on-a-temporary-string%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The code exhibits undefined behavior.
get_data()
returns a temporary which expires at the end of the full expression (*):
const char* data = get_data().c_str() ;
// ^~~~~~~~~~ ^
// this evaluates |
// to a prvalue |
// temporary expires here
data
points to an internal of that object, so after the temporary ends you are left with a dangling pointer. Accessing it leads to Undefined Behavior. So the next line std::cout << data << "n";
makes the whole program exhibit Undefined Behavior.
*) There is an exception to this rule which doesn't apply here. If a prvalue is directly bound to a reference, the lifetime of the prvalue is extended to the lifetime of the reference.
For instance, this would have been fine:
int main()
const std::string& ref = get_data();
const char* data = ref.c_str();
std::cout << data << "n";
return 0;
Your answer should include something with the words sequence point to get my upvote, because people still search for that - even though it doesn't appear in the standard.
– Wyck
5 hours ago
1
@Wyck I don't see how sequence points are relevant here. The only thing that matters is the lifetime of the temporary. And that lifetime is until the end of the full expression it appears on.
– bolov
5 hours ago
1
@Wyck newer standards don't use "sequence points" indeed. They use "sequenced after" and "sequenced before". I still don't see the connection to the problem at hand... Maybe I am missing something, could you please tell how sequencing relates here?
– bolov
5 hours ago
1
@Wyck a single statement can possibly have multiple sequencing considerations, but they would not affect when a temporary is destroyed
– kmdreko
5 hours ago
1
The only thing that this doesn't cover is the Asker's statement that judging that the returned string is immutable suggests that they might not know that the string literal and the returnedstd::string
are separate objects.
– user4581301
5 hours ago
|
show 2 more comments
The code exhibits undefined behavior.
get_data()
returns a temporary which expires at the end of the full expression (*):
const char* data = get_data().c_str() ;
// ^~~~~~~~~~ ^
// this evaluates |
// to a prvalue |
// temporary expires here
data
points to an internal of that object, so after the temporary ends you are left with a dangling pointer. Accessing it leads to Undefined Behavior. So the next line std::cout << data << "n";
makes the whole program exhibit Undefined Behavior.
*) There is an exception to this rule which doesn't apply here. If a prvalue is directly bound to a reference, the lifetime of the prvalue is extended to the lifetime of the reference.
For instance, this would have been fine:
int main()
const std::string& ref = get_data();
const char* data = ref.c_str();
std::cout << data << "n";
return 0;
Your answer should include something with the words sequence point to get my upvote, because people still search for that - even though it doesn't appear in the standard.
– Wyck
5 hours ago
1
@Wyck I don't see how sequence points are relevant here. The only thing that matters is the lifetime of the temporary. And that lifetime is until the end of the full expression it appears on.
– bolov
5 hours ago
1
@Wyck newer standards don't use "sequence points" indeed. They use "sequenced after" and "sequenced before". I still don't see the connection to the problem at hand... Maybe I am missing something, could you please tell how sequencing relates here?
– bolov
5 hours ago
1
@Wyck a single statement can possibly have multiple sequencing considerations, but they would not affect when a temporary is destroyed
– kmdreko
5 hours ago
1
The only thing that this doesn't cover is the Asker's statement that judging that the returned string is immutable suggests that they might not know that the string literal and the returnedstd::string
are separate objects.
– user4581301
5 hours ago
|
show 2 more comments
The code exhibits undefined behavior.
get_data()
returns a temporary which expires at the end of the full expression (*):
const char* data = get_data().c_str() ;
// ^~~~~~~~~~ ^
// this evaluates |
// to a prvalue |
// temporary expires here
data
points to an internal of that object, so after the temporary ends you are left with a dangling pointer. Accessing it leads to Undefined Behavior. So the next line std::cout << data << "n";
makes the whole program exhibit Undefined Behavior.
*) There is an exception to this rule which doesn't apply here. If a prvalue is directly bound to a reference, the lifetime of the prvalue is extended to the lifetime of the reference.
For instance, this would have been fine:
int main()
const std::string& ref = get_data();
const char* data = ref.c_str();
std::cout << data << "n";
return 0;
The code exhibits undefined behavior.
get_data()
returns a temporary which expires at the end of the full expression (*):
const char* data = get_data().c_str() ;
// ^~~~~~~~~~ ^
// this evaluates |
// to a prvalue |
// temporary expires here
data
points to an internal of that object, so after the temporary ends you are left with a dangling pointer. Accessing it leads to Undefined Behavior. So the next line std::cout << data << "n";
makes the whole program exhibit Undefined Behavior.
*) There is an exception to this rule which doesn't apply here. If a prvalue is directly bound to a reference, the lifetime of the prvalue is extended to the lifetime of the reference.
For instance, this would have been fine:
int main()
const std::string& ref = get_data();
const char* data = ref.c_str();
std::cout << data << "n";
return 0;
edited 5 hours ago
answered 6 hours ago
bolovbolov
33.1k876141
33.1k876141
Your answer should include something with the words sequence point to get my upvote, because people still search for that - even though it doesn't appear in the standard.
– Wyck
5 hours ago
1
@Wyck I don't see how sequence points are relevant here. The only thing that matters is the lifetime of the temporary. And that lifetime is until the end of the full expression it appears on.
– bolov
5 hours ago
1
@Wyck newer standards don't use "sequence points" indeed. They use "sequenced after" and "sequenced before". I still don't see the connection to the problem at hand... Maybe I am missing something, could you please tell how sequencing relates here?
– bolov
5 hours ago
1
@Wyck a single statement can possibly have multiple sequencing considerations, but they would not affect when a temporary is destroyed
– kmdreko
5 hours ago
1
The only thing that this doesn't cover is the Asker's statement that judging that the returned string is immutable suggests that they might not know that the string literal and the returnedstd::string
are separate objects.
– user4581301
5 hours ago
|
show 2 more comments
Your answer should include something with the words sequence point to get my upvote, because people still search for that - even though it doesn't appear in the standard.
– Wyck
5 hours ago
1
@Wyck I don't see how sequence points are relevant here. The only thing that matters is the lifetime of the temporary. And that lifetime is until the end of the full expression it appears on.
– bolov
5 hours ago
1
@Wyck newer standards don't use "sequence points" indeed. They use "sequenced after" and "sequenced before". I still don't see the connection to the problem at hand... Maybe I am missing something, could you please tell how sequencing relates here?
– bolov
5 hours ago
1
@Wyck a single statement can possibly have multiple sequencing considerations, but they would not affect when a temporary is destroyed
– kmdreko
5 hours ago
1
The only thing that this doesn't cover is the Asker's statement that judging that the returned string is immutable suggests that they might not know that the string literal and the returnedstd::string
are separate objects.
– user4581301
5 hours ago
Your answer should include something with the words sequence point to get my upvote, because people still search for that - even though it doesn't appear in the standard.
– Wyck
5 hours ago
Your answer should include something with the words sequence point to get my upvote, because people still search for that - even though it doesn't appear in the standard.
– Wyck
5 hours ago
1
1
@Wyck I don't see how sequence points are relevant here. The only thing that matters is the lifetime of the temporary. And that lifetime is until the end of the full expression it appears on.
– bolov
5 hours ago
@Wyck I don't see how sequence points are relevant here. The only thing that matters is the lifetime of the temporary. And that lifetime is until the end of the full expression it appears on.
– bolov
5 hours ago
1
1
@Wyck newer standards don't use "sequence points" indeed. They use "sequenced after" and "sequenced before". I still don't see the connection to the problem at hand... Maybe I am missing something, could you please tell how sequencing relates here?
– bolov
5 hours ago
@Wyck newer standards don't use "sequence points" indeed. They use "sequenced after" and "sequenced before". I still don't see the connection to the problem at hand... Maybe I am missing something, could you please tell how sequencing relates here?
– bolov
5 hours ago
1
1
@Wyck a single statement can possibly have multiple sequencing considerations, but they would not affect when a temporary is destroyed
– kmdreko
5 hours ago
@Wyck a single statement can possibly have multiple sequencing considerations, but they would not affect when a temporary is destroyed
– kmdreko
5 hours ago
1
1
The only thing that this doesn't cover is the Asker's statement that judging that the returned string is immutable suggests that they might not know that the string literal and the returned
std::string
are separate objects.– user4581301
5 hours ago
The only thing that this doesn't cover is the Asker's statement that judging that the returned string is immutable suggests that they might not know that the string literal and the returned
std::string
are separate objects.– user4581301
5 hours ago
|
show 2 more comments
Yes it is, but not the way you're doing it.
If you did this:
std::cout << get_data().c_str() << 'n';
you'd be just fine.
That's because a temporary is guaranteed to live for the lifetime of the full expression it was created in. It may live longer in certain, very specific circumstances.
If you bind a const reference to a temporary, it's lifetime will be extended to be the lifetime of the name it was bound to. So, code like this:
std::string const &x = get_data();
std::cout << x.c_str() << 'n';
would also work because the temporary returned by get_data
would be bound to the reference named x
, and so as long as x
remained a valid name to use, the temporary would still exist.
1
A const reference, I think you mean.
– Nemo
2 hours ago
add a comment |
Yes it is, but not the way you're doing it.
If you did this:
std::cout << get_data().c_str() << 'n';
you'd be just fine.
That's because a temporary is guaranteed to live for the lifetime of the full expression it was created in. It may live longer in certain, very specific circumstances.
If you bind a const reference to a temporary, it's lifetime will be extended to be the lifetime of the name it was bound to. So, code like this:
std::string const &x = get_data();
std::cout << x.c_str() << 'n';
would also work because the temporary returned by get_data
would be bound to the reference named x
, and so as long as x
remained a valid name to use, the temporary would still exist.
1
A const reference, I think you mean.
– Nemo
2 hours ago
add a comment |
Yes it is, but not the way you're doing it.
If you did this:
std::cout << get_data().c_str() << 'n';
you'd be just fine.
That's because a temporary is guaranteed to live for the lifetime of the full expression it was created in. It may live longer in certain, very specific circumstances.
If you bind a const reference to a temporary, it's lifetime will be extended to be the lifetime of the name it was bound to. So, code like this:
std::string const &x = get_data();
std::cout << x.c_str() << 'n';
would also work because the temporary returned by get_data
would be bound to the reference named x
, and so as long as x
remained a valid name to use, the temporary would still exist.
Yes it is, but not the way you're doing it.
If you did this:
std::cout << get_data().c_str() << 'n';
you'd be just fine.
That's because a temporary is guaranteed to live for the lifetime of the full expression it was created in. It may live longer in certain, very specific circumstances.
If you bind a const reference to a temporary, it's lifetime will be extended to be the lifetime of the name it was bound to. So, code like this:
std::string const &x = get_data();
std::cout << x.c_str() << 'n';
would also work because the temporary returned by get_data
would be bound to the reference named x
, and so as long as x
remained a valid name to use, the temporary would still exist.
edited 2 hours ago
answered 4 hours ago
OmnifariousOmnifarious
41k11101162
41k11101162
1
A const reference, I think you mean.
– Nemo
2 hours ago
add a comment |
1
A const reference, I think you mean.
– Nemo
2 hours ago
1
1
A const reference, I think you mean.
– Nemo
2 hours ago
A const reference, I think you mean.
– Nemo
2 hours ago
add a comment |
Aknin Abdo is a new contributor. Be nice, and check out our Code of Conduct.
Aknin Abdo is a new contributor. Be nice, and check out our Code of Conduct.
Aknin Abdo is a new contributor. Be nice, and check out our Code of Conduct.
Aknin Abdo is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55408411%2fis-it-safe-to-use-c-str-on-a-temporary-string%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Where does that string that gets returned go after
c_str()
is called and returns a pointer to some data?– tadman
6 hours ago
2
stackoverflow.com/questions/23464504/…
– Wyck
6 hours ago
2
Probably not a duplicate but helpful: stackoverflow.com/questions/349025/…. Also your interview question is missing
#include <string>
so technically it would be a compiler error ;)– Tas
6 hours ago
1
I'm a bit surprised that the documentation for
std::string::c_str
doesn't mention destruction of the string as grounds for the returned pointer being invalidated (unless you consider the destructor to be a non-const member function). I think many people coming from a C background would benefit from having this written explicitly– alter igel
5 hours ago
1
@Tas: io-streams implement the shift-operators including overloads on basic_string ,so it needs its definition which requires it to include <string>. So it can't be a compiler error.
– engf-010
5 hours ago