Several "=" operators overloads??

You can overload the assignment operator as much as you want. It's probably a mistake to do so, though.

Why is this a mistake? For example, suppose you have 3 classes:
- a list
- a queue and
- a stack
Why not overload the = operator for these classes. For example, this could be done just to copy the contents of each structure to another.The problem is that operator = is also used by the compiler to do "silent" conversions.

Operator = is one of those operators where you may not think it's being called, but it is. What happens in a non-trivial program is that you will get these conversions happening, and not know that they're happening until you discover that things are just not working right. When you try to debug these problems, you'll be shocked how many times "=" is actually being called by the compiler, everything from resolving arguments to functions, to returning values. One of those calls will more than likely be something that you didn't want to do, but it's being done anyway.

My opinion is operator = should only be overloaded when your object needs to assign to an object of the same type, and the default assignment is not adequate. Just willy-nilly creating your own assignments to different classes by overloading operator = is just inviting trouble.

Regards,

Paul McKenzie

originally posted by Paul McKenzie:
My opinion is operator = should only be overloaded when your object needs to assign to an object of the same type

what about assign a base to a successor when the successor unique members
could have some default values?

Regards,
Guy

Why is this a mistake? For example, suppose you have 3 classes:
- a list
- a queue and
- a stack
Why not overload the = operator for these classes. For example, this could be done just to copy the contents of each structure to another.
Because a list is NOT a queue and a queue is NOT a stack. I prefer the code I write to match up conceptually to what I'm doing. When you say you want to be able to write "list = stack", you appear to be saying that you wish to make your list EQUAL TO your stack, that is, identical. But you can't, because a list is NOT a stack. It's a nonsensical concept. Look, though, at what you ACTUALLY want to do with that statement: you want to set the the elements of the list from the elements of the stack. Now assuming that the respective elements are of compatible types, that is a reasonable thing to do. But it's not setting the list EQUAL TO the stack, it's setting the list's elements to be the same as those in the stack.

(BTW: for the moment, I'm ignoring the semantics of a stack which say that the only thing of interest on a stack is the top element, so the concept of copying the contents of stack to a list without destroying the stack is semantically suspect.)

Now the concept of creating a list whose elements are based on those of a given stack is admirably served by a constructor taking two iterators (as exists in the STL). It's not a problem to have an assignment operator between two objects of the same type (the compiler gives you one for free), so to replace the contents of an existing list with the contents of another type of container, we create a temporary of the correct type and then do the assignment:

my_list = list(my_stack.begin(), my_stack.end());

This bit of code my take fractionally longer to write, but the intention is explicit - there is no possibility that is is a typo (and, therefore, a bug).

By providing too many "shortcuts", you provide more ways to prevent the compiler from spotting the bugs in your code and warning you about them. Remember, if you provide that assignment operator, you are telling the compiler that that assignment is OK - at all times/i]. You are saying that it is [i]never a mistake to do that assignment. I'll lay odds that there are plenty of parts of your code where it would be a mistake. The compiler won't tell you about them, though, and you'll be off on a long search tracking down that bug. Doing it my way, for those bits where it does make sense, I've kept the compiler happy, but it will still complain if I've made a typo - bug squashed before it manifested. Also, people coming at my code later on will also have the confidence that that assigment was not a typo, but was deliberate.