Back to General and Gameplay Programming

Operator Overloading C++

noodleBowl · 2015-02-13T23:26:15

Over the weekend I learn about overloading operators in C++.The idea behind this is pretty simple, but I still am wondering about a few things For operators like operator+ and operator+=, why is it that when it comes to operator+= we return a reference? Where with the operator+ we return a copy of a temporary object? Why don't they both return the same things, either both return a copy or a reference? //Overlaod code for += and + //Operator+ MyObject MyObject::operator+(const MyObject &obj) { MyObject tmp; tmp.val = val + obj.val; return tmp; } //Operator+= MyObject &MyObject::operator+=(const MyObject &obj) { this->val += obj.val; return *this; } Also I have a few questions when it comes to the copy assignment operator:MyObject &MyObject::operator=(const MyObject &obj)1. Why is there a destructor called when there is no local object being created in the code? What is actually being destroyed here?2. When I was reading up on copy assignment operators, I saw that I should have the self-check guard in order to prevent memory leaks and dangling pointers when it comes to objects that use dynamic memory allocation. But I'm wondering do I need this if I know my class is not going to have any dynamic memory stuff? Or is this something I should do just as a "good practice"?3. When read about this operator and dynamic memory allocation, the topic of the "copy swap" idiom comes about. Should I only follow this idiom when dealing with dynamic memory, because an exception could get thrown when trying to allocate data? Or is this something I should just practice as well? //Basic copy assignment operator with self assignment gaurd MyObject &Myobject::operator=(const Myobject &obj) { if(this != &obj) { this->val = obj.val; } return *this }

General and Gameplay Programming Programming

Started by noodleBowl February 09, 2015 02:24 PM

26 comments, last by Ravyne 9 years, 2 months ago

noodleBowl

718

Author

February 10, 2015 03:05 AM

But that code isn't "nothing", it is "something". That "something" has side effects (it prints some text), which means that your program is doing different things whether there is an extra copy or not (either prints some additional text or doesn't print some additional text), and the compiled can't know if that is important or not to you personally.

The mere fact that you print something means that there is now an observable difference between making the extra copy and not. That may, as SiCrane suggested, very well be the deciding factor for the compiler's ability and/or desire to remove the extra copy. And that could be a problem for you; attempts you make to observe if this extra copy is made or not, could actual end up being the reason why it is made.

I see. I guess I'll have to remove the std::cout statement, then step through with the debugger, and count the deconstructors. That should work right?

On a side note, when it comes to overloading operators I have added them to my header file under the public section.
Now whenever I use a dot operator to call a method or etc I see all of my overloads, which makes sense they are all under the public section.
But I was wondering can I move them so they will not show up?I tried to just move them to the private section but the compiler (visual studio 2013) can't see them.

Is there a way to make them 'private' so they do not show when I use the dot operator?

Also if I overload the operator+ using MyObject as a param and then again with a float as the param. Should the float param be const float?


MyObject &MyObject::operator+=(const MyObject &obj) //Normal overload with MyObject as param

MyObject &MyObject::operator+=(float obj) //Should I use const in the param (const float obj)

ChaosEngine

5,385

February 10, 2015 04:01 AM

noodleBowl, the term is "destructor" not "deconstructor". Just telling you this to help avoid confusion in the future.

Second, why wouldn't you want the operators to show up? They are publicly accessible members of the class.

Finally, there's no harm in doing


MyObject &MyObject::operator+=(const float obj)

but there's no real gain either. Because C++ passes by value, the float you pass into the += operator will be a copy.

if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight

frob

46,223

February 10, 2015 04:15 AM

Is there a way to make them 'private' so they do not show when I use the dot operator?

That's your editor trying to be helpful. It is trying to offer choices to auto complete whatever you would be typing next.

The built-in list does not filter, it rather stupidly displays a list of everything it can find.

There are many plugins, such as RottonTomato's Visual Assist X or ReSharper or CodeRush, all of them replace the IntelliSense autocomplete list with more realistic values.

SmkViper

5,396

February 10, 2015 02:46 PM

noodleBowl, the term is "destructor" not "deconstructor". Just telling you this to help avoid confusion in the future.

Second, why wouldn't you want the operators to show up? They are publicly accessible members of the class.

Finally, there's no harm in doing
MyObject &MyObject::operator+=(const float obj)
but there's no real gain either. Because C++ passes by value, the float you pass into the += operator will be a copy.

You could argue that there is use in defining it const to prevent you from changing the value in the function. Even though it doesn't really make any difference for the generated code (probably, compilers are devilishly smart these days) I find it sometimes helps make my code cleaner and easier to understand. Plus putting const on everything you can is just a good habit to get into. (And not being able to do it in C# drives me up the wall sometimes...)

Though if I'm doing that I usually leave the const off of the function header in the .h file, adding it to the .cpp file only since the caller doesn't really care one way or the other since it's by-value.

ChaosEngine

5,385

February 10, 2015 09:56 PM

You could argue that there is use in defining it const to prevent you from changing the value in the function.

True. Whether that's useful or not depends on the function itself, but in general I'd agree it's good programming practice.

Plus putting const on everything you can is just a good habit to get into.

Agreed. In fact, I'd go further. In some ways, I think variables should be const by default and marked as mutable otherwise, but I understand the historical reasons why C++ couldn't do that.

(And not being able to do it in C# drives me up the wall sometimes...)

Amen brother. Lack of const objects/methods is one of my pet hates in c#.

Though if I'm doing that I usually leave the const off of the function header in the .h file, adding it to the .cpp file only since the caller doesn't really care one way or the other since it's by-value.

Never knew you could do that. Wouldn't it change the function signature and mess up the linker?

if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight

alvaro

21,604

February 10, 2015 10:36 PM

Though if I'm doing that I usually leave the const off of the function header in the .h file, adding it to the .cpp file only since the caller doesn't really care one way or the other since it's by-value.

Never knew you could do that. Wouldn't it change the function signature and mess up the linker?

No, whether the parameters are const or not is not part of the signature.

Ravyne

14,306

February 11, 2015 02:09 AM

But to clarify, and maybe I'm wrong, isn't it more accurate to say that the constness of the parameter itself is not part of the signature, but that the constness of an object taken in as a pointer or reference is part of the signature?

In other words a parameter, whether a value, or a reference, or a pointer, const doesn't matter -- but that is not the same thing as that which it is a pointer or a reference to, and its constness, which does matter.

throw table_exception("(? ???)? ? ???");

SmkViper

5,396

February 11, 2015 02:18 PM

But to clarify, and maybe I'm wrong, isn't it more accurate to say that the constness of the parameter itself is not part of the signature, but that the constness of an object taken in as a pointer or reference is part of the signature?

In other words a parameter, whether a value, or a reference, or a pointer, const doesn't matter -- but that is not the same thing as that which it is a pointer or a reference to, and its constness, which does matter.

Nope. Const is a compiler-enforced "promise" that can be easily violated with casting or aliasing. AFAIK, the linker doesn't even see it, since the compiler would have done all the enforcement work ahead of time.

Edit: Actually I think I see what you're getting at. And I think you're right. Const has to be part of the signature if the pointed-to object is const, because the compiler has to enforce that you don't pass const objects to parameters that take objects as non-const. But if you're taking it by value it doesn't matter because the value is copied and the copy will be const/non-const no matter what the source was.

Scorpie

256

February 11, 2015 02:50 PM

But to clarify, and maybe I'm wrong, isn't it more accurate to say that the constness of the parameter itself is not part of the signature, but that the constness of an object taken in as a pointer or reference is part of the signature?

In other words a parameter, whether a value, or a reference, or a pointer, const doesn't matter -- but that is not the same thing as that which it is a pointer or a reference to, and its constness, which does matter.

Nope. Const is a compiler-enforced "promise" that can be easily violated with casting or aliasing. AFAIK, the linker doesn't even see it, since the compiler would have done all the enforcement work ahead of time.

Edit: Actually I think I see what you're getting at. And I think you're right. Const has to be part of the signature if the pointed-to object is const, because the compiler has to enforce that you don't pass const objects to parameters that take objects as non-const. But if you're taking it by value it doesn't matter because the value is copied and the copy will be const/non-const no matter what the source was.

He is right indeed, I was writing it up again but you both explained it already.

Quotes from the standard are metioned here on SO: http://stackoverflow.com/a/3681190 and in plain english the post below.

Khatharr

8,814

February 13, 2015 05:23 AM

//Operator+

MyObject MyObject::operator+(const MyObject &obj)
{
  MyObject tmp;
  tmp.val += obj.val;
  return tmp;
}
This is off-topic, but this does not look correct. I believe you would want tmp.val to contain (this->val + obj.val).

I'm going in... Cover me...

//Operator+ (refactored to trip up JPs)

MyObject MyObject::operator+(MyObject obj) {
  obj.val += val;
  return obj;
}

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

Operator Overloading C++

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Operator Overloading C++

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines