434,778 Members | 1,318 Online
Need help? Post your question and get tips & solutions from a community of 434,778 IT Pros & Developers. It's quick & easy.

# difference in following code

 P: n/a For an exercise I had to write a class that would do math operations on complex numbers. The main point of the exercise was overloading various operators. One of them was the conjugate operator "~". I overloaded it thus: void Complecks::operator~(const Complecks& q)const{ im = - im; } I figured the invoking object would have it's "im" member negated, which seemed to be the purpose. But that didn't work. Fortunately for me, the author of this book gave the solution to this problem and his method was: Complecks Complecks::operator~(const Complecks& q)const{ Complecks t; t.real = real - q.real; t.im = im - q.im; return t; } Okay. But the method is invoked with a call like " ~c " where c is a complex number with a real and imaginary component, no assignement operator is involved. So, doesn't the latter code just return back to "c"? Why wouldn't the first code work the same? Jun 20 '07 #1
9 Replies

 P: n/a waltbrad wrote: For an exercise I had to write a class that would do math operations on complex numbers. The main point of the exercise was overloading various operators. One of them was the conjugate operator "~". I overloaded it thus: void Complecks::operator~(const Complecks& q)const{ im = - im; What's 'im'? Is that a member? Of what, 'q' or '*this'? If it's (supposedly) the member of '*this', then you're trying to change the '*this' object, right? And you just declared that object 'const' by putting 'const' after the function declaration (before the curly brace). So, even if the syntax were accepted (I don't think it should be, since ~ is an unary operator, so it shouldn't have any arguments), the compilation shouldn't let you change a const object. } I figured the invoking object would have it's "im" member negated, which seemed to be the purpose. But that didn't work. Fortunately for me, the author of this book *What* book? I am asking so that we'd recommend people against it since it doesn't seem to have correct C++ examples. gave the solution to this problem and his method was: Complecks Complecks::operator~(const Complecks& q)const{ Complecks t; t.real = real - q.real; t.im = im - q.im; return t; } Okay. OKAY? Are you saying it will compile? How is 'Complecks' defined? But the method is invoked with a call like " ~c " where c is a complex number with a real and imaginary component, no assignement operator is involved. So, doesn't the latter code just return back to "c"? No. Why wouldn't the first code work the same? It's up to you of course, but the operator~ (just like the operator! or the operator-) is NOT supposed to change the object for which it is called. It is supposed to return a new object: Complecks Complecks::operator~() const { return Complecks(real, -im); // there is a c-tor for that I hope } or Complecks operator~(Complecks const& q) { return Complecks(q.real(), -q.imaginary()); } (supposing that you have defined 'Complecks' with needed constructor and accessors). V -- Please remove capital 'A's when replying by e-mail I do not respond to top-posted replies, please don't ask Jun 20 '07 #2

 P: n/a Victor Bazarov

 P: n/a BobR wrote: Victor Bazarov >>void Complecks::operator~(const Complecks& q)const{im = - im; What's 'im'? Is that a member? Of what, 'q' or '*this'? If it's(supposedly) the member of '*this', then you're trying to change the'*this' object, right? And you just declared that object 'const' byputting 'const' after the function declaration (before the curlybrace). So, even if the syntax were accepted >** (I don't think itshould be, since ~ is an unary operator, so it shouldn't have anyarguments) ** .... It should have one argument. A non-static member shouldn't have any _additional_ arguments. Some (many) newbies do not realise that there is an implicit argument for any non-static member function, so my note was for those. "TiCpp" v1 says: " The bitwise not (~, also called the ones complement operator) is a unary operator - it only takes ** one argument ** (all other bitwise operators are binary operators). Bitwise not produces the opposite of the input bit - a one if the input bit is zero, a zero if the input bit is one. " I think you meant that if a 'this' pointer is passed in, the '&q' arg makes it two? [ so make it 'static' member.

 P: n/a On Jun 20, 4:50 pm, "Victor Bazarov" >(std::istream& is, Complecks& q); }; =========================== and then... =========== //one of two constructors: Complecks::Complecks(double p, double q){ real = p; im = q; } //and the final way I implemented the "~" operator: Complecks Complecks::operator~(){ Complecks obj; obj.real = real; obj.im = -im; return obj; } ================ I don't know if this is all you want to see or not. But apparently there is a "this" operator. But the method is invoked with a call like " ~c " where c is a complex number with a real and imaginary component, no assignement operator is involved. So, doesn't the latter code just return back to "c"? No. Right. Here I was wrong. Although the example program didn't use "~c" with an assignment operator, it could have done that. Instead the "~c" was used in an ostream, and it returned the value to the ostream. But, I guess the only reason the overloaded operator wouldn't return a value with the first code was that it was declared void and constant. Why wouldn't the first code work the same? It's up to you of course, but the operator~ (just like the operator! or the operator-) is NOT supposed to change the object for which it is called. It is supposed to return a new object: Complecks Complecks::operator~() const { return Complecks(real, -im); // there is a c-tor for that I hope } Yes, your code would also work. or Complecks operator~(Complecks const& q) { return Complecks(q.real(), -q.imaginary()); } (supposing that you have defined 'Complecks' with needed constructor and accessors). This wouldn't work with the code I have, but yes, I can see how that would work with the right setup. Thanks for your input, I think this has cleared up some of my understanding. But, do you agree that the overloaded ~ operator function does have a "this" pointer? Jun 22 '07 #5