Overloading operators

This is a discussion on Overloading operators within the C++ Programming forums, part of the General Programming Boards category; I wouldn't say *ptr is a reference; *ptr is an object. You create the reference through something else, say: void ...

  1. #31
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,625
    I wouldn't say *ptr is a reference; *ptr is an object. You create the reference through something else, say:

    void foo(int &i);
    foo(*ptr);

    So i is the reference, not *ptr strictly. What makes it confusing in the case of overloaded ops, is that this happens behind the scenes.

  2. #32
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413
    Dangerous to think of it like that.
    It should be

    int* ptr;

    This proves that ptr's type is int*. And the "*" means it's a pointer. That is, it stores a memory address to an object of type int.
    We can always reassign the pointer with another memory address because it's a pointer. The type is int*.
    But to get whatever it points to, and do stuff with that, we need to say "go to where this pointer points", and that you do with the dereference operator *.
    So *ptr now gives you the actual int it points to.
    Thus,

    int* p = new int;
    int& r1 = p; // Error; p is of type int*.
    int& r2 = *p; // Okay: *p is the real int, hence its type is int.
    delete p;

    Take note that *p is NOT a reference. It is an object of type int.
    r1 and r2 are references (though r1 is not initialized correctly and will give a compile error).
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #33
    Registered User
    Join Date
    Aug 2009
    Posts
    140
    Quote Originally Posted by Elysia View Post
    iMalc claims that the object itself is being passed by reference, and no its address, because to access the object, we always have to dereference a pointer to it, or access it directly. Hence no address.
    What is it precisely you mean by that? I thought they the two were equal? I mean, if I have

    Code:
    int testFunc(int* a)
    and I call it using testFunc(&integer_var), then the address is being passed. But what is the difference between this and when a variable is passed "by reference"? If possible, can I ask you to make an example? This way I wont possibly misinterpret what you say.




    Furthermore, according to http://msdn.microsoft.com/en-us/libr...8VS.80%29.aspx,

    Code:
    myDate.setMonth( 3 );
    
    can be interpreted this way:
    
    setMonth( &myDate, 3 );
    I believe this is the same as my example in this post?

  4. #34
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413
    Passing by address and by reference are two different concepts.
    Code:
    void foo(T* p); // This is pass by address/pointer
    void foo(T& p); // This is pass by reference
    When you pass by address, a copy of the address is made and copied into the pointer argument in the function. This is a given. That is how the standard mandates it.
    References are different, however. The standard states that they are aliases.
    So
    Code:
    void foo(int& n)
    {
        // n is now an alias of main_n. That is, they are the same variable, but with different names.
        // n is a different name, another alias, if you will, of main_n in main.
    }
    
    int main()
    {
        int main_n = 0;
        foo(main_n);
    }
    In practice, many compilers implement references using pointers, but those are details we do not need to concern ourselves with. What the standard says is enough.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #35
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,313
    Quote Originally Posted by Niels_M
    But what is the difference between this and when a variable is passed "by reference"?
    So we have instead:
    Code:
    int testFunc(int& a)
    then the call is testFunc(integer_var). Besides the obvious difference in syntax, there is the difference in the type of the parameter a, i.e., a is not a pointer but a reference.

    Quote Originally Posted by Niels_M
    I believe this is the same as my example in this post?
    Yes. Now, let me tell you that:
    Code:
    a += b;
    where a is of some class type, and operator+= is a member, is equivalent to:
    Code:
    a.operator+=(b);
    Hence, using the same reasoning, it can be interpreted as:
    Code:
    operator+=(&a, b);
    But hold on... what is the type of a? Is it a pointer? No, it is a class type. So, if you want to use this reasoning to insist that the left hand argument of operator+= can be a pointer, then you must also agree that the type of myDate is a pointer type. But myDate is not of a pointer type, hence we derive a contradiction, proving that such an assertion is false.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  6. #36
    Registered User
    Join Date
    Aug 2009
    Posts
    140
    Ok, so the reason why you all say that the object is passed by reference to this is because this simply is an aliases for the object. It also makes sense, since I cannot change what this points to.

    But then the obvious question would be to ask: "Why is this is a pointer, and not a reference?". And the answer is given by iMalc:
    Quote Originally Posted by iMalc View Post
    Because the evolution of the C++ language includes in its history, a few mistakes. One of them is that 'this' should have been a reference rather than a pointer.
    Is this correctly understood?

  7. #37
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413
    No, we're saying it's passed by reference to *this.
    this is a pointer. Thus, *this is the object that it's pointing to.
    It makes sense that you cannot change what this points to because they would screw up a lot of things.

    As to the question of why this is a pointer and not a reference, you are correct. Basically, the this keyword was introduced before references were, thus it was set in stone for all eternity to be a pointer unless the committee wanted to break backward compatibility.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #38
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,313
    Quote Originally Posted by Niels_M
    Ok, so the reason why you all say that the object is passed by reference to this is because this simply is an aliases for the object. It also makes sense, since I cannot change what this points to.
    More accurately, *this is an alias for the object.

    Quote Originally Posted by Niels_M
    But then the obvious question would be to ask: "Why is this is a pointer, and not a reference?". And the answer is given by iMalc:
    Yes. You can read Stroustrup's answer to the FAQ: Why is "this" not a reference?
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  9. #39
    Registered User
    Join Date
    Aug 2009
    Posts
    140
    There is still one thing bothering me. Laserlight previously told me that the arguments of a function get passed as if they are used to initialize the operands, so in this case we would have something like

    Code:
    setMonth(Date* this, int mn)
    ..
    ...
    
    setMonth( &myDate, 3 );
    i.e. Date* this=&myDate. How would you explain this in the light of *this being a reference?

  10. #40
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,625
    I think you're being comically thick about this whole issue but it's not really your fault you're missing a critical fact:

    Quote Originally Posted by Me, earlier
    I wouldn't say *ptr is a reference; *ptr is an object.
    *this may be thought of as a reference, I GUESS, but it is not even a reference until you assign it to a reference. *this fetches your object, the object you are working inside of, and it should follow that you have access to everything in the object based on having its location and whether or not it violates access restrictions. Using the layout in memory, methods and et cetera are a single instruction away.

    The point of the recent posts is that this is used as a reference is. Therefore this is a reference, in every sense but type: this is created with an address when an object is constructed and is immutable. That is what it shares in common with references.

    If this were a reference it would be perfectly fine. You wouldn't even be able to ask this.

    void setMonth (Date &this, int month);
    setMonth( birthday, myMonth );

    But it's not. The only reason its not is because references weren't invented when classes were invented. If you're bothered ... well, we all are. C++ bothers people too much every day, and some people feel rather strongly about their opinion.
    Last edited by whiteflags; 09-12-2010 at 11:01 PM.

  11. #41
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,288
    Quote Originally Posted by Niels_M View Post
    There is still one thing bothering me. Laserlight previously told me that the arguments of a function get passed as if they are used to initialize the operands, so in this case we would have something like

    Code:
    setMonth(Date* this, int mn)
    ..
    ...
    
    setMonth( &myDate, 3 );
    i.e. Date* this=&myDate. How would you explain this in the light of *this being a reference?
    This might help:
    Although that is how you could emmulate a member function in C, that's not accurate as for how C++ conceptually does it. C++ does it more like this:
    Code:
    setMonth(Date &self, int mn)
    {
        Date *this = &self;
        // business as usual...
        this->mn = mn;
    }
    
    setMonth(myDate, 3);
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

Page 3 of 3 FirstFirst 123
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Overloading operators
    By ugmusicbiz in forum C++ Programming
    Replies: 2
    Last Post: 02-13-2009, 12:41 PM
  2. Replies: 16
    Last Post: 10-27-2007, 12:42 PM
  3. Overloading fstream's << and >> operators
    By VirtualAce in forum C++ Programming
    Replies: 2
    Last Post: 04-09-2007, 03:17 AM
  4. operators overloading
    By waqasriazpk in forum C++ Programming
    Replies: 1
    Last Post: 07-26-2002, 01:05 AM
  5. Overloading operators...
    By Unregistered in forum C++ Programming
    Replies: 4
    Last Post: 11-21-2001, 07:24 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21