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()?How do I iterate over the words of a string?Why is 'this' a pointer and not a reference?Why does std::ends cause string comparison to fail?Return value for a << operator function of a custom string class in C++Returning value from a functionconst qualifier for a string literalEasiest way to convert int to string in C++How can I convert a std::basic_string type to an array of char type?C++ Concatenating const char * with string, only const char * printsSystemC sc_uint from String Object

Anatomically Correct Mesopelagic Aves

Is the concept of a "numerable" fiber bundle really useful or an empty generalization?

If the heap is initialized for security, then why is the stack uninitialized?

Why did we only see the N-1 starfighters in one film?

How can I quit an app using Terminal?

Anatomically Correct Strange Women In Ponds Distributing Swords

How to count occurrences of text in a file?

If I blow insulation everywhere in my attic except the door trap, will heat escape through it?

Can a caster that cast Polymorph on themselves stop concentrating at any point even if their Int is low?

How to get regions to plot as graphics

Is it a good idea to use COLUMN AS (left([Another_Column],(4)) instead of LEFT in the select?

What makes a siege story/plot interesting?

Only print output after finding pattern

How to Reset Passwords on Multiple Websites Easily?

Is HostGator storing my password in plaintext?

Why do professional authors make "consistency" mistakes? And how to avoid them?

Should I tutor a student who I know has cheated on their homework?

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

Apart from "berlinern", do any other German dialects have a corresponding verb?

Science fiction (dystopian) short story set after WWIII

How to write the block matrix in LaTex?

Implement the Thanos sorting algorithm

What is the purpose of the Evocation wizard's Potent Cantrip feature?

How do I construct this japanese bowl?



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()?How do I iterate over the words of a string?Why is 'this' a pointer and not a reference?Why does std::ends cause string comparison to fail?Return value for a << operator function of a custom string class in C++Returning value from a functionconst qualifier for a string literalEasiest way to convert int to string in C++How can I convert a std::basic_string type to an array of char type?C++ Concatenating const char * with string, only const char * printsSystemC sc_uint from String Object










6















#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!










share|improve this question









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















6















#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!










share|improve this question









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













6












6








6








#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!










share|improve this question









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.












#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!







c++






share|improve this question









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.











share|improve this question









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.









share|improve this question




share|improve this question








edited 2 hours ago









alter igel

3,44711230




3,44711230






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.









asked 2 hours ago









Aknin AbdoAknin Abdo

341




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.





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.






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












  • 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







1




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





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




2





stackoverflow.com/questions/23464504/…

– Wyck
2 hours ago





stackoverflow.com/questions/23464504/…

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




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





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












2 Answers
2






active

oldest

votes


















7














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;






share|improve this answer

























  • 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


















1














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.






share|improve this answer























    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


















    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









    7














    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;






    share|improve this answer

























    • 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















    7














    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;






    share|improve this answer

























    • 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













    7












    7








    7







    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;






    share|improve this answer















    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;







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 2 hours ago

























    answered 2 hours ago









    bolovbolov

    33.1k876140




    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

















    • 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






    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




    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





    @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




    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





    @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




    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





    @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




    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





    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













    1














    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.






    share|improve this answer



























      1














      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.






      share|improve this answer

























        1












        1








        1







        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 1 hour ago









        OmnifariousOmnifarious

        41k11101162




        41k11101162




















            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.












            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Францішак Багушэвіч Змест Сям'я | Біяграфія | Творчасць | Мова Багушэвіча | Ацэнкі дзейнасці | Цікавыя факты | Спадчына | Выбраная бібліяграфія | Ушанаванне памяці | У філатэліі | Зноскі | Літаратура | Спасылкі | НавігацыяЛяхоўскі У. Рупіўся дзеля Бога і людзей: Жыццёвы шлях Лявона Вітан-Дубейкаўскага // Вольскі і Памідораў з песняй пра немца Адвакат, паэт, народны заступнік Ашмянскі веснікВ Минске появится площадь Богушевича и улица Сырокомли, Белорусская деловая газета, 19 июля 2001 г.Айцец беларускай нацыянальнай ідэі паўстаў у бронзе Сяргей Аляксандравіч Адашкевіч (1918, Мінск). 80-я гады. Бюст «Францішак Багушэвіч».Яўген Мікалаевіч Ціхановіч. «Партрэт Францішка Багушэвіча»Мікола Мікалаевіч Купава. «Партрэт зачынальніка новай беларускай літаратуры Францішка Багушэвіча»Уладзімір Іванавіч Мелехаў. На помніку «Змагарам за родную мову» Барэльеф «Францішак Багушэвіч»Памяць пра Багушэвіча на Віленшчыне Страчаная сталіца. Беларускія шыльды на вуліцах Вільні«Krynica». Ideologia i przywódcy białoruskiego katolicyzmuФранцішак БагушэвічТворы на knihi.comТворы Францішка Багушэвіча на bellib.byСодаль Уладзімір. Францішак Багушэвіч на Лідчыне;Луцкевіч Антон. Жыцьцё і творчасьць Фр. Багушэвіча ў успамінах ягоных сучасьнікаў // Запісы Беларускага Навуковага таварыства. Вільня, 1938. Сшытак 1. С. 16-34.Большая российская1188761710000 0000 5537 633Xn9209310021619551927869394п

            Partai Komunis Tiongkok Daftar isi Kepemimpinan | Pranala luar | Referensi | Menu navigasidiperiksa1 perubahan tertundacpc.people.com.cnSitus resmiSurat kabar resmi"Why the Communist Party is alive, well and flourishing in China"0307-1235"Full text of Constitution of Communist Party of China"smengembangkannyas

            ValueError: Expected n_neighbors <= n_samples, but n_samples = 1, n_neighbors = 6 (SMOTE) The 2019 Stack Overflow Developer Survey Results Are InCan SMOTE be applied over sequence of words (sentences)?ValueError when doing validation with random forestsSMOTE and multi class oversamplingLogic behind SMOTE-NC?ValueError: Error when checking target: expected dense_1 to have shape (7,) but got array with shape (1,)SmoteBoost: Should SMOTE be ran individually for each iteration/tree in the boosting?solving multi-class imbalance classification using smote and OSSUsing SMOTE for Synthetic Data generation to improve performance on unbalanced dataproblem of entry format for a simple model in KerasSVM SMOTE fit_resample() function runs forever with no result