Is it safe to use c_str() on a temporary string?

#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? Thanks in advance!

edited 2 hours ago

alter igel

3,44711230

asked 2 hours ago

Aknin Abdo

341

New contributor

1

Where does that string that gets returned go after c_str() is called and returns a pointer to some data?

– tadman
2 hours ago

2

stackoverflow.com/questions/23464504/…

– Wyck
2 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
2 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
2 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
2 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;

}

edited 2 hours ago

alter igel

3,44711230

asked 2 hours ago

Aknin Abdo

341

New contributor

1

Where does that string that gets returned go after c_str() is called and returns a pointer to some data?

– tadman
2 hours ago

2

stackoverflow.com/questions/23464504/…

– Wyck
2 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
2 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
2 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
2 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;

}

edited 2 hours ago

alter igel

3,44711230

asked 2 hours ago

Aknin Abdo

341

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;

}

c++

edited 2 hours ago

alter igel

3,44711230

asked 2 hours ago

Aknin Abdo

341

New contributor

edited 2 hours ago

alter igel

3,44711230

asked 2 hours ago

Aknin Abdo

341

New contributor

edited 2 hours ago

alter igel

3,44711230

edited 2 hours ago

alter igel

3,44711230

edited 2 hours ago

alter igel

3,44711230

asked 2 hours ago

Aknin Abdo

341

New contributor

asked 2 hours ago

Aknin Abdo

341

asked 2 hours ago

Aknin Abdo

341

New contributor

Aknin Abdo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

1

Where does that string that gets returned go after c_str() is called and returns a pointer to some data?

– tadman
2 hours ago

2

stackoverflow.com/questions/23464504/…

– Wyck
2 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
2 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
2 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
2 hours ago

|
show 5 more comments

1

Where does that string that gets returned go after c_str() is called and returns a pointer to some data?

– tadman
2 hours ago

2

stackoverflow.com/questions/23464504/…

– Wyck
2 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
2 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
2 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
2 hours ago

Where does that string that gets returned go after c_str() is called and returns a pointer to some data?

– tadman
2 hours ago

stackoverflow.com/questions/23464504/…

– Wyck
2 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
2 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
2 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
2 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;

}

edited 2 hours ago

answered 2 hours ago

bolov

33.1k876140

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
2 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
2 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
2 hours ago

1

@Wyck a single statement can possibly have multiple sequencing considerations, but they would not affect when a temporary is destroyed

– kmdreko
2 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 returned std::string are separate objects.

– user4581301
1 hour 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 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.

answered 1 hour ago

Omnifarious

41k11101162

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.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');

var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);

});

Post as a guest

Name

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

Name

Required, but never shown

2 Answers
2

active

oldest

votes

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

*) 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 2 hours ago

answered 2 hours ago

bolov

33.1k876140

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
2 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
2 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
2 hours ago

1

@Wyck a single statement can possibly have multiple sequencing considerations, but they would not affect when a temporary is destroyed

– kmdreko
2 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 returned std::string are separate objects.

– user4581301
1 hour 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

*) 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 2 hours ago

answered 2 hours ago

bolov

33.1k876140

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
2 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
2 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
2 hours ago

1

@Wyck a single statement can possibly have multiple sequencing considerations, but they would not affect when a temporary is destroyed

– kmdreko
2 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 returned std::string are separate objects.

– user4581301
1 hour 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

*) 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 2 hours ago

answered 2 hours ago

bolov

33.1k876140

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

*) 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 2 hours ago

answered 2 hours ago

bolov

33.1k876140

edited 2 hours ago

answered 2 hours ago

bolov

33.1k876140

answered 2 hours ago

bolov

33.1k876140

answered 2 hours ago

bolov

33.1k876140

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
2 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
2 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
2 hours ago

1

@Wyck a single statement can possibly have multiple sequencing considerations, but they would not affect when a temporary is destroyed

– kmdreko
2 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 returned std::string are separate objects.

– user4581301
1 hour 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
2 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
2 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
2 hours ago

1

@Wyck a single statement can possibly have multiple sequencing considerations, but they would not affect when a temporary is destroyed

– kmdreko
2 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 returned std::string are separate objects.

– user4581301
1 hour 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
2 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
2 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
2 hours ago

@Wyck a single statement can possibly have multiple sequencing considerations, but they would not affect when a temporary is destroyed

– kmdreko
2 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
1 hour 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 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.

answered 1 hour ago

Omnifarious

41k11101162

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 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.

answered 1 hour ago

Omnifarious

41k11101162

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 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.

answered 1 hour ago

Omnifarious

41k11101162

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 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.

answered 1 hour ago

Omnifarious

41k11101162

answered 1 hour ago

Omnifarious

41k11101162

answered 1 hour ago

Omnifarious

41k11101162

answered 1 hour ago

Omnifarious

41k11101162

add a comment |

Aknin Abdo is a new contributor. Be nice, and check out our Code of Conduct.

draft saved

draft discarded

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.

draft saved

draft discarded

Sign up or log in

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

Post as a guest

Name

Required, but never shown

Sign up or log in

Post as a guest

Name

Required, but never shown

Sign up or log in

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Bdtyk