Why doesn't this modify the pointer?

Discussion in 'C++' started by Markus Dehmann, Feb 18, 2005.

  1. I guess this is a kind of newbie question (since most pointer questions are
    newbie questions).

    In the program below, modify(string* s) is supposed to change the content
    that s points to. But the main() function shows that nothing is changed at
    all!

    What am I doing wrong?



    #include <iostream>
    #include <vector>
    using namespace std;

    class Modifier{
    private:
    vector<string> newStrings;
    public:
    void modify(string* s){
    string newString = "test"; // toy example,
    // could be *s transformed into upper case etc.
    newStrings.push_back(newString);
    s = &(newStrings[newStrings.size() - 1]); // point to new string
    }
    };

    int main(){
    Modifier m;
    string s = "Hello World";
    m.modify(&s);
    cout << s << endl; // should be "test", but is still "Hello World"
    return(EXIT_SUCCESS);
    }
     
    Markus Dehmann, Feb 18, 2005
    #1
    1. Advertising

  2. Markus Dehmann

    Ron Natalie Guest

    Markus Dehmann wrote:

    > In the program below, modify(string* s) is supposed to change the content
    > that s points to. But the main() function shows that nothing is changed at
    > all!


    That's because you don't change it.

    > void modify(string* s){


    This function gets the pointer to the string by value.

    > s = &(newStrings[newStrings.size() - 1]); // point to new string


    This does exactly what you say. It makes the local variable s point to the
    new string, it has no affect on the value in the calling function (main).

    It's unclear what you want to do here. If you want to assign the value of
    the new string into the old string in the parent you can do:

    *s = newString;

    Which chages what s points to (that is, the string called s in the parent).

    You'll have to give us a more concise description of what you are trying to accomplish.
     
    Ron Natalie, Feb 18, 2005
    #2
    1. Advertising

  3. Ron Natalie wrote:

    > Markus Dehmann wrote:
    >
    >> In the program below, modify(string* s) is supposed to change the content
    >> that s points to. But the main() function shows that nothing is changed
    >> at all!

    >
    > That's because you don't change it.
    >
    >> void modify(string* s){

    >
    > This function gets the pointer to the string by value.
    >
    >> s = &(newStrings[newStrings.size() - 1]); // point to new string

    >
    > This does exactly what you say. It makes the local variable s point to
    > the new string, it has no affect on the value in the calling function
    > (main).
    >
    > It's unclear what you want to do here. If you want to assign the value
    > of the new string into the old string in the parent you can do:
    >
    > *s = newString;


    That works. The *s instead of s does the trick.

    I'm surprised though, that this is valid code. I thought newString will be
    destroyed at the end of the modify function:

    void modify(string* s){
    string newString = "test";
    *s = newString;
    }

    It goes out of scope. So, if I say *s=newString, and access s later, from
    the main() function, isn't that undefined behavior, because s points to
    someting that has gone out of scope?

    (I was using the weird vector (newStrings) strategy in order to avoid that,
    but it seems that's not necessary?)

    Thanks
    Markus
     
    Markus Dehmann, Feb 18, 2005
    #3
  4. "Markus Dehmann" <> wrote...
    > Ron Natalie wrote:
    >
    >> Markus Dehmann wrote:
    >>
    >>> In the program below, modify(string* s) is supposed to change the
    >>> content
    >>> that s points to. But the main() function shows that nothing is changed
    >>> at all!

    >>
    >> That's because you don't change it.
    >>
    >>> void modify(string* s){

    >>
    >> This function gets the pointer to the string by value.
    >>
    >>> s = &(newStrings[newStrings.size() - 1]); // point to new string

    >>
    >> This does exactly what you say. It makes the local variable s point to
    >> the new string, it has no affect on the value in the calling function
    >> (main).
    >>
    >> It's unclear what you want to do here. If you want to assign the value
    >> of the new string into the old string in the parent you can do:
    >>
    >> *s = newString;

    >
    > That works. The *s instead of s does the trick.
    >
    > I'm surprised though, that this is valid code. I thought newString will be
    > destroyed at the end of the modify function:
    >
    > void modify(string* s){
    > string newString = "test";
    > *s = newString;
    > }
    >
    > It goes out of scope. So, if I say *s=newString, and access s later, from
    > the main() function, isn't that undefined behavior, because s points to
    > someting that has gone out of scope?


    The 'newString' does go out of scope. However, before it dies, its *value*
    is _copied_ into the object pointed to by 's'. So, when the original object
    goes out of scope and is destroyed, a copy of its value lives on.

    > (I was using the weird vector (newStrings) strategy in order to avoid
    > that,
    > but it seems that's not necessary?)


    Probably. I can't say I know what you mean by "vector strategy", but it
    sounds that it wasn't necessary if you can achieve the same thing through
    simple copy-assignment.

    V
     
    Victor Bazarov, Feb 18, 2005
    #4
  5. Markus Dehmann wrote:
    >
    > > It's unclear what you want to do here. If you want to assign the value
    > > of the new string into the old string in the parent you can do:
    > >
    > > *s = newString;

    >
    > That works. The *s instead of s does the trick.


    Yep.
    But your further reply shows that you haven't understood what it does.

    's' is a pointer to a string.
    This pointer is passed from main, and points to the string 'main::s'
    (That is variable s in main).

    '*s' dereferences that pointer and thus you get a hand on the string
    object itself.

    *s = That string object (the one in main, because this is where this
    pointer points to) gets a new value.

    *s = newString; In particular it gets a copy of the value in newString

    >
    > I'm surprised though, that this is valid code. I thought newString will be
    > destroyed at the end of the modify function:
    >
    > void modify(string* s){
    > string newString = "test";
    > *s = newString;
    > }
    >
    > It goes out of scope.


    It doesn't matter.
    When newString runs out of scope, its value has long been copied to the string
    object where s points to (and that is the string variable s in main).

    > So, if I say *s=newString, and access s later, from
    > the main() function, isn't that undefined behavior, because s points to
    > someting that has gone out of scope?


    In that function, s always points to the same memory object. And that is the
    variable s in main(). It never points to something else.

    When you say:
    *s = ...
    you are changing the object where s points to. You are not changing where
    s points to. If you want to change where s (the pointer in modify()) points
    to you simply would do
    s = ...

    (But note: 's' in modify() is a local variable, so changing where this pointer
    points to has no effect on the caller)

    --
    Karl Heinz Buchegger
     
    Karl Heinz Buchegger, Feb 18, 2005
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jeff Rodriguez
    Replies:
    5
    Views:
    407
    CBFalconer
    Nov 15, 2003
  2. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    997
    Mark Rae
    Dec 21, 2006
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,269
    Smokey Grindel
    Dec 2, 2006
  4. Replies:
    10
    Views:
    745
    Chris Torek
    Feb 4, 2005
  5. jimjim
    Replies:
    16
    Views:
    876
    Jordan Abel
    Mar 28, 2006
Loading...

Share This Page