The meaning of a = b in object oriented languages

Discussion in 'C++' started by Summercool, Sep 18, 2007.

  1. Summercool

    Summercool Guest

    The meaning of a = b in object oriented languages.
    ====================================================

    I just want to confirm that in OOP, if a is an object, then b = a is
    only copying the reference.

    (to make it to the most basic form:

    a is 4 bytes, let's say, at memory location 0x10000000 to 0x10000003

    b is 4 bytes, let's say, at memory location 0x20000000 to 0x20000003

    in 0x10000000 to 0x10000003, it is the value 0xF0000000, pointing to
    an object

    b = a just means
    copy the 4 bytes 0xF0 0x00 0x00 0x00 into 0x20000000 to 0x2000003
    so that b now points to 0xF0000000 which is the same object.)


    so essentially, a is just a pointer to an object.

    and b = a just means that put that same pointer into b.

    and that's why in Python or Ruby, it is like:

    >>> a = {"a" : 1, "b" : 2}
    >>> b = a
    >>> a

    {'a': 1, 'b': 2}
    >>> b

    {'a': 1, 'b': 2}
    >>> a["a"] = 999
    >>> a

    {'a': 999, 'b': 2}
    >>> b

    {'a': 999, 'b': 2}

    so most or all object oriented language do assignment by reference?
    is there any object oriented language actually do assignment by
    value? I kind of remember in C++, if you do

    Animal a, b;

    a = b will actually be assignment by value.
    while in Java, Python, and Ruby, there are all assignment by
    reference. ("set by reference")

    Is that the case: if a is an object, then b = a is only copying the
    reference?
    Summercool, Sep 18, 2007
    #1
    1. Advertising

  2. Summercool wrote:
    > so most or all object oriented language do assignment by reference?
    > is there any object oriented language actually do assignment by
    > value? I kind of remember in C++, if you do
    >
    > Animal a, b;
    >
    > a = b will actually be assignment by value.
    > while in Java, Python, and Ruby, there are all assignment by
    > reference. ("set by reference")
    >
    > Is that the case: if a is an object, then b = a is only copying the
    > reference?


    Yes, your understanding is exactly correct; C++ will assign by value
    unless you explicitly use pointers, but the other languages will assign
    by reference (except for primitive types).

    --
    "Always look on the bright side of life."
    To reply by email, replace no.spam with my last name.
    Russell Wallace, Sep 18, 2007
    #2
    1. Advertising

  3. Summercool

    Ben Finney Guest

    Summercool <> writes:

    > I just want to confirm that in OOP, if a is an object, then b = a is
    > only copying the reference.


    Whether the language is OO or not has no bearing on this question. The
    semantics of the assignment operator can and do differ between
    languages, orthogonal to whether OOP is involved.

    --
    \ "Our task must be to free ourselves from our prison by widening |
    `\ our circle of compassion to embrace all humanity and the whole |
    _o__) of nature in its beauty." —Albert Einstein |
    Ben Finney
    Ben Finney, Sep 18, 2007
    #3
  4. Summercool

    Jim Langston Guest

    "Summercool" <> wrote in message
    news:...
    >
    > The meaning of a = b in object oriented languages.
    > ====================================================
    >
    > I just want to confirm that in OOP, if a is an object, then b = a is
    > only copying the reference.
    >
    > (to make it to the most basic form:
    >
    > a is 4 bytes, let's say, at memory location 0x10000000 to 0x10000003
    >
    > b is 4 bytes, let's say, at memory location 0x20000000 to 0x20000003
    >
    > in 0x10000000 to 0x10000003, it is the value 0xF0000000, pointing to
    > an object
    >
    > b = a just means
    > copy the 4 bytes 0xF0 0x00 0x00 0x00 into 0x20000000 to 0x2000003
    > so that b now points to 0xF0000000 which is the same object.)
    >
    > so essentially, a is just a pointer to an object.
    >
    > and b = a just means that put that same pointer into b.
    >
    > and that's why in Python or Ruby, it is like:
    >
    >>>> a = {"a" : 1, "b" : 2}
    >>>> b = a
    >>>> a

    > {'a': 1, 'b': 2}
    >>>> b

    > {'a': 1, 'b': 2}
    >>>> a["a"] = 999
    >>>> a

    > {'a': 999, 'b': 2}
    >>>> b

    > {'a': 999, 'b': 2}
    >
    > so most or all object oriented language do assignment by reference?
    > is there any object oriented language actually do assignment by
    > value? I kind of remember in C++, if you do
    >
    > Animal a, b;
    >
    > a = b will actually be assignment by value.
    > while in Java, Python, and Ruby, there are all assignment by
    > reference. ("set by reference")
    >
    > Is that the case: if a is an object, then b = a is only copying the
    > reference?


    In C++ the default assignment constructor is virtually the same as the
    default copy constructor, which is sometimes called a bitwise copy, although
    that is not strictly true. For POD types (Plain Old Data) what you are
    showing is true, it's a bitwise copy, very similar to memcpy( destination,
    source, sizeof( destination) ). For non POD types, however, that is not
    true as objects inside the class or structure will have their assignment
    operators called, and they may be overridden. A prime example of this is
    std::string. If the std::string member was bitwise copied, then there would
    be two instances of a std::string pointing to the same memory locations
    (since std::string typically stores the strings data via a pointer).

    Assignment operators in C++ should attempt to prevent two pointers poining
    to the same memory location. Consier a simple class (untested):

    class Foo
    {
    public:
    char* Data;
    int DataSize;
    Foo( int Size ): DataSize( Size ) { Data = new char[Size]; }
    ~Foo() { delete Data[]; }
    };

    Now, if we leave the class at this, we get into problems. The default copy
    constructor and assignment operators will do a bitwise copy on the pointer
    Data. I.E.

    int main()
    {
    Foo bar1( 10 );
    Foo bar2( 20 );
    bar2 = bar1; // Lots of problems
    }

    First off, the default assignment operator will simply copy the pointer from
    bar1 (which points to 10 characters) into bar2, overwriting bar2's. Since
    we no longer have a pointer to the data from bar2 we can not delete it,
    causing a memory leak. Also, at this point bar1 and bar2's Data pointers
    point to the same memory location. Changing the contents of one will change
    the contents of the other, since they are one in the same. Also, when the
    destructors are called, both will attempt to delete[] the same pointer, the
    first one will succeed, the second one will cause an error as the pointer
    has already been freed. So we need to override the copy constructor and
    assignment operators to fix this. So we add to Foo:

    Foo& operator=( const Foo& rhs )
    {
    delete[] Data;
    Data = new char[rhs.DataSize];
    memcpy( Data, rhs.Data, rhs.DataSize );
    DataSize = rhs.DataSize;
    }

    You can see that we have to manually do some things. We have to delete[]
    our pointer, new a new buffer, copy the cotents, copy the DataSize over,
    none of which the default assignment operator would of done. The copy
    constructor would be similar, we just wouldn't have to delete[] Data;
    because nothing has been allocated yet.

    Incidently, there may be errors in the code I've shown here if you attempt
    to compile it. Be forewarned.
    Jim Langston, Sep 18, 2007
    #4
  5. Summercool

    Summercool Guest

    Re: The meaning of a = b in object oriented languages

    On Sep 17, 11:04 pm, Lloyd Linklater <> wrote:
    > SpringFlowers AutumnMoon wrote:
    > > Is that the case: if a is an object, then b = a is only copying the
    > > reference?

    >
    > That and it adds a counter.
    >
    > a = ["foo", "bar"]
    > b = a
    > b[0] = "bite me"
    > p a, b
    >
    > a = "different"
    > p a, b
    >
    > ***
    >
    > In the first print, we get
    > ["something else", "bar"]
    > ["something else", "bar"]
    >
    > showing that changing b changes a, as expected. However, if we change
    > a, b is NOT changed as seen in the second print.
    >
    > "different"
    > ["something else", "bar"]
    >
    > That means that there is a counter inside that says to separate the two
    > or b would have changed with a as a changed with b initially.


    i think the line

    a = "different"

    means a is now set to a pointer to the String object with content
    "different".
    or that "a is now a reference to the String object."

    and b is still a reference to the Array object. so that's why a and b
    print out different things. they point to different objects.

    i think:

    whenever in Ruby, Python, and Java,

    a is never an object. a is always a "reference to an object"... this
    will solve a lot of puzzles when we don't understand some code
    behaviors.

    when a writing or a book reads "a is a Hash object; a is an Array
    object; or a is an Animal object" it is just a short form to say that
    "a is a reference to that object."

    b = a means "whatever a is referencing to, now b is referencing it
    too".

    so that's why a[1] = "foobar" will change what b will display, but
    a = "foobar" will not change what b will display. (because a[1] =
    "foobar" says "what is a referencing? go there and change its
    content that has the index 1" and when b goes there to see it, it is
    also changed.)
    Summercool, Sep 18, 2007
    #5
  6. Summercool a écrit :
    >
    >
    > The meaning of a = b in object oriented languages.
    > ====================================================

    <zip>

    Oups, reading the subject I thought it was a Xah Lee post.


    ;-)
    Laurent Pointal, Sep 18, 2007
    #6
  7. Laurent Pointal schreef:
    > Summercool a écrit :
    >>
    >> The meaning of a = b in object oriented languages.
    >> ====================================================

    > <zip>
    >
    > Oups, reading the subject I thought it was a Xah Lee post.


    me too ...

    --
    The saddest aspect of life right now is that science gathers knowledge
    faster than society gathers wisdom.
    -- Isaac Asimov

    Roel Schroeven
    Roel Schroeven, Sep 18, 2007
    #7
  8. Summercool

    Lew Guest

    Re: The meaning of a = b in object oriented languages

    Summercool wrote:
    > when a writing or a book reads "a is a Hash object; a is an Array
    > object; or a is an Animal object" it is just a short form to say that
    > "a is a reference to that object."
    >
    > b = a means "whatever a is referencing to, now b is referencing it
    > too".
    >
    > so that's why a[1] = "foobar" will change what b will display, but
    > a = "foobar" will not change what b will display.


    You can't do both in Java. Is a an array or a String? If a is a String and b
    is an array, then neither `a = b' nor `b = a' will compile in Java.

    Java is a strongly-typed, compiled language which means it does more static
    type checking and thus would reject treating a as both an array and a String.
    In that environment the programmer must choose one or the other.

    Otherwise what you say is exactly correct.

    > (because a[1] = "foobar" says "what is a referencing? go there and change its
    > content that has the index 1" and when b goes there to see it, it is
    > also changed.)


    Speaking just of Java, it's useful to distinguish a variable from an object
    (instance). As you point out, the variable represents a reference to the
    instance. The variable has a compile-time type in Java, which may be
    different from the run-time type of the object, albeit compatible.

    C++ is similar in this respect. Python and Ruby are more, shall we say,
    flexible in their type systems.

    Both jet liners and hang gliders have their uses, both are flight, and neither
    is really suitable for the other's purpose.

    --
    Lew
    Lew, Sep 18, 2007
    #8
  9. Summercool

    Lew Guest

    Roel Schroeven wrote:
    > Laurent Pointal schreef:
    >> Summercool a écrit :
    >>>
    >>> The meaning of a = b in object oriented languages.
    >>> ====================================================

    >> <zip>
    >>
    >> Oups, reading the subject I thought it was a Xah Lee post.

    >
    > me too ...


    Nah, this dude's all right, so far. As if my opinion mattered.

    Stay with it, Summercool. It's what discussion groups are for.

    Here's why the reaction: cross-posting of computer-science-type essays,
    something Xah Lee does. But he recycles all his decades-old crap and really
    doesn't participate in the discussion. This isn't that at all.

    --
    Lew
    Lew, Sep 18, 2007
    #9
  10. Summercool

    Bryan Olson Guest

    Jim Langston wrote:
    > Assignment operators in C++ should attempt to prevent two pointers poining
    > to the same memory location. Consier a simple class (untested):
    >
    > class Foo
    > {
    > public:
    > char* Data;
    > int DataSize;
    > Foo( int Size ): DataSize( Size ) { Data = new char[Size]; }
    > ~Foo() { delete Data[]; }
    > };


    [...]
    > Foo& operator=( const Foo& rhs )
    > {
    > delete[] Data;
    > Data = new char[rhs.DataSize];
    > memcpy( Data, rhs.Data, rhs.DataSize );
    > DataSize = rhs.DataSize;
    > }
    >
    > You can see that we have to manually do some things. We have to delete[]
    > our pointer, new a new buffer, copy the cotents, copy the DataSize over,
    > none of which the default assignment operator would of done.

    [...]
    > Incidently, there may be errors in the code I've shown here if you attempt
    > to compile it. Be forewarned.


    There's the "self-assignment" bug. See the popular C++ FAQ.

    Follow-ups to comp.lang.c++
    --
    --Bryan
    Bryan Olson, Sep 19, 2007
    #10
  11. Lew schreef:
    > Roel Schroeven wrote:
    >> Laurent Pointal schreef:
    >>> Summercool a écrit :
    >>>> The meaning of a = b in object oriented languages.
    >>>> ====================================================
    >>> <zip>
    >>>
    >>> Oups, reading the subject I thought it was a Xah Lee post.

    >> me too ...

    >
    > Nah, this dude's all right, so far. As if my opinion mattered.
    >
    > Stay with it, Summercool. It's what discussion groups are for.
    >
    > Here's why the reaction: cross-posting of computer-science-type essays,
    > something Xah Lee does. But he recycles all his decades-old crap and really
    > doesn't participate in the discussion. This isn't that at all.


    I fully agree and I didn't in any way mean to compare Summercool to Xah
    Lee. My apologies to Summercool if anyone interpreted it that way.

    It's just that somehow the subject seems to follow the same template as
    what I've become used to from Xah Lee. I almost skipped reading the post
    because of that. Once I started reading it though, it became immediately
    clear that it was not comparable to Xah Lee's postings in any way, shape
    or form.

    --
    The saddest aspect of life right now is that science gathers knowledge
    faster than society gathers wisdom.
    -- Isaac Asimov

    Roel Schroeven
    Roel Schroeven, Sep 19, 2007
    #11
  12. Summercool

    Ken Bloom Guest

    Re: The meaning of a = b in object oriented languages

    On Tue, 18 Sep 2007 18:02:59 -0400, Lew wrote:

    > Summercool wrote:
    >> when a writing or a book reads "a is a Hash object; a is an Array
    >> object; or a is an Animal object" it is just a short form to say that
    >> "a is a reference to that object."
    >>
    >> b = a means "whatever a is referencing to, now b is referencing it
    >> too".
    >>
    >> so that's why a[1] = "foobar" will change what b will display, but a
    >> = "foobar" will not change what b will display.

    >
    > You can't do both in Java. Is a an array or a String? If a is a String
    > and b is an array, then neither `a = b' nor `b = a' will compile in
    > Java.
    >
    > Java is a strongly-typed, compiled language which means it does more
    > static type checking and thus would reject treating a as both an array
    > and a String.
    > In that environment the programmer must choose one or the other.


    In this Java example, a and b are statically typed to be of type Object.
    Both Strings and Arrays descend from Object. (And primatives like
    integers and the like will be autoboxed into descendants of Object).




    --
    Ken Bloom. PhD candidate. Linguistic Cognition Laboratory.
    Department of Computer Science. Illinois Institute of Technology.
    http://www.iit.edu/~kbloom1/
    Ken Bloom, Sep 19, 2007
    #12
  13. Summercool

    Lew Guest

    Re: The meaning of a = b in object oriented languages

    Lew wrote:
    >> Java is a strongly-typed, compiled language which means it does more
    >> static type checking and thus would reject treating a as both an array
    >> and a String.
    >> In that environment the programmer must choose one or the other.


    Ken Bloom wrote:
    > In this Java example, a and b are statically typed to be of type Object.
    > Both Strings and Arrays [sic] descend from Object. (And primatives [sic] like
    > integers and the like will be autoboxed into descendants of Object).


    That doesn't make Strings and arrays assignment compatible, and besides, it
    isn't so.

    It was not stated by the OP that they were statically typing the variable to
    Object. In fact, their example used a type "Animal". They also used the
    syntax "a[1]", which is not possible in Java with a variable of type Object.
    So clearly a and b are /not/ statically typed to Object.

    Unless you meant "/if/ a and b are statically typed [to] Object" that the
    assignment will work, which is true but of sharply limited usefulness.

    In that case, you are a) defeating Java's type system and b) not getting the
    benefit of the Stringness or arrayness of the variable. This is in contrast
    to the dynamically-typed languages wherein the variable will behave like an
    object of the runtime type, unlike in Java.

    Back to the OP's example:
    Summercool wrote:
    >> so that's why a[1] = "foobar" will change what b will display, but
    >> a = "foobar" will not change what b will display.


    Again, this cannot be done in Java. The same variable a cannot be set to a
    String and still be used with array syntax.

    --
    Lew
    Lew, Sep 19, 2007
    #13
  14. Russell Wallace wrote:
    > Summercool wrote:
    >> so most or all object oriented language do assignment by reference?
    >> is there any object oriented language actually do assignment by
    >> value? I kind of remember in C++, if you do
    >>
    >> Animal a, b;
    >>
    >> a = b will actually be assignment by value.
    >> while in Java, Python, and Ruby, there are all assignment by
    >> reference. ("set by reference")
    >>
    >> Is that the case: if a is an object, then b = a is only copying the
    >> reference?

    >
    > Yes, your understanding is exactly correct; C++ will assign by value
    > unless you explicitly use pointers, but the other languages will assign
    > by reference (except for primitive types).


    Ada also assigns by value absent explicit use of access variables
    (similar to pointers or references).

    The question, in fact, is meaningless. Java has a certain defined
    behavior. C++ has a certain defined behavior. Smalltalk has a certain
    defined behavior. LISP has a certain defined behavior. Ada has a certain
    defined behavior. Object-oriented languages as a class do not.
    --
    John W. Kennedy
    "The poor have sometimes objected to being governed badly; the rich have
    always objected to being governed at all."
    -- G. K. Chesterton. "The Man Who Was Thursday"
    John W. Kennedy, Sep 21, 2007
    #14
    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. Summercool
    Replies:
    13
    Views:
    534
    John W. Kennedy
    Sep 21, 2007
  2. Summercool
    Replies:
    15
    Views:
    442
    John W. Kennedy
    Sep 21, 2007
  3. Replies:
    2
    Views:
    411
    Bruno Desthuilliers
    May 26, 2008
  4. rolo
    Replies:
    3
    Views:
    167
    Robert Klemme
    Apr 9, 2004
  5. Summercool
    Replies:
    21
    Views:
    307
    Todd Benson
    Sep 21, 2007
Loading...

Share This Page