1 Shaktizragore

Non-Member Assignment Operator Java

Override operator= for non-class (ie primitive) types like int, char *, etc.

I have a problem which I can't seem to find others who have the same problem. I have a custom class, call it foomatic. I want to define how foomatic is reference in assignments with =. For example, consider the following code:

foomatic object1;
string object1Name;
int object1Size;

objectName = object1;
object1Size = object1;

Here, I have control of the object on the right of the =...the rvalue. I don't have control over the objects on the left side of the =. I know that I could extend string class in this example, but I don't want to create a new class for every custom object. This means I would have to go through ALL my source code and update the extended string class, for example, just so I can make the above code valid. Furthermore, I am not even aware of a way to override operator= for primitive types, such as int, or char *, etc.

Thanks,
Anthony

You can do as you want.

You need to override the = operator in the global namespace (outside of your class).


Obviously, the function overload needs to be a friend to foomatic.

Now you can say things like



Just keep in mind that at least one of the operands must be a user-defined type (like a class).

If you want more information, a simple Google of "c++ operator overloading" produces some nice results.

Hope this helps.

[edit] Hey Zaita, you on the east cost of USA also?
Also, I can't believe I forgot that one. Nice!
Douas:
You need to override the = operator in the global namespace (outside of your class).

No. That isn't possible. You can do that with other binary operators, but the assignment operator must be a non-static member function. Zaita's solution should work, but he better declare the operators const:
Wow, such great I will try these out today. I will post back up to confirm which solution worked.

Thanks!
Ropez: That's more in his implementation. Maybe he wants to alter the returned name at some point. Because it's being returned by value rather than reference the const keyword would only be a preference thing.
So, Zaita's suggestion worked and so did ropez's additon of "const". What exactly is set as constant with ropez's solution? Does it set the returned object/variable constant?
Nothing. Because the operator returns a value, not a reference.

"Const methods are a way for us to say that a method does not modify the member variables of a class. It's a hint both to the programmer and the compiler that a given method doesn't change the internal state of a class."

"is often missed is that by extension a const method cannot call a non-const method (and the compiler will complain if you try). Since we assume that a non-const method does modify the member variables of our class, we can't call that from a method where we've promised not to do just that."
The const keyword in this case has nothing to do with the return type. It's necessary to qualify the function as const to be able to call it with a const foomatic object as receiver ("this").

Without the const keyword, this code won't compile:


Since the assignment doesn't change the rvalue, it should be possible to do this even with a const reference. Therefore, you should add the const keyword.

BTW: The error message would be something like "calling operator int() discards qualifiers".
Hmmm indeed correct. Does this offer any optimization benefits when using the const keyword?
What exactly is set as constant with ropez's solution?


The implicit first parameter.

All member function has a "hidden" parameter called this, e.g.
Does this offer any optimization benefits when using the const keyword?

Not that I know of, but an interesting question.
Topic archived. No new replies allowed.

This chapter from Object-Oriented Computation in C++ and Java: A Practical Guide to Design Patterns for Object-Oriented Computing covers the choices we face among language facilities that have duplicate or overlapping functionality, the background of various traditions in C++ and Java programming, and established principles of good programming practice as they apply to building and using object-oriented classes.

This chapter is from the book 

2.1. Our emphasis

This chapter is not a language tutorial. I assume you already have experience in defining object-oriented classes in C++ or Java or both. The emphasis here is on

  • the choices we face among language facilities that have duplicate or overlapping functionality
  • the background of various traditions in C++ and Java programming
  • established principles of good programming practice as they apply to building and using object-oriented classes

Unlike later chapters, the following sections address the topics in both languages. Even if you have absolutely no immediate interest in one of the languages, you should resist the temptation to skip over those explanations. By understanding the fundamental approaches in C++ and Java and the differences between them, you’ll develop a stronger command of object-oriented class design and an informed appreciation of the strengths and weaknesses of each language.

Leave a Comment

(0 Comments)

Your email address will not be published. Required fields are marked *