suppose addition operator or subtraction
Main Topics
Browse All TopicsHow can I add three more additional operators for the following program.
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
>> suppose addition operator or subtraction
Do you want them as free standard operators or class member operators? See an example, below, of how to implement these as class member operators. Note that you must return a copy of a new object because the standard + and - operators shouldn't modify the original objects and because of this the member functions should be declared const.
BTW: I don't agree with this...
// overloaded assignment operator;
// const return avoids: ( a1 = a2 ) = a3
const Array &Array::operator=( const Array &right )
It is perfectly acceptable semantics in C/C++ to be able to do chained assignments
x = y = z; // This is a perfectly valid bit of code.
>> Chains work fine with const return references.
Yes, you're right (my head was in the clouds there); however, I still don't agree with it for the following reason...
Firstly, let's take the implementation of the std::vector's assignment operator as an example...
_Myt& operator=(const _Myt& _Right); // Does not return const reference
Secondly, it means the assignment semantics will not be the same as the standard built-in or synthesised assignment operators. This can impact ones ability to write generic code as the behaviour would be unexpected.
>> suppose addition operator or subtraction
If addition is defined as creating a new array which includes all elements of both input arrays, it is
Array Array::operator+(const Array & right)
{
int i = 0;
int n = 0;
Array arr(getSize()+right.getSiz
for (i = 0; i < getSize(); ++i)
arr[i] = (*this)[i];
for (n = 0; n < right.getSize(); ++n,++i)
arr[i] = right[n];
return arr;
}
Note, you didn't post the array.h header. So, I didn't know whether you have an insert or append (push_back) member function.
If addition is defined as creating a new array which includes all unique elements of both input arrays, it is
Array Array::operator+(const Array & right)
{
int i = 0;
int n = 0;
int k = 0;
// make a temporary copy same size as left array
Array temp(getSize());
bool dupl =false;
// assume both input arrays have no duplicate entries themselves
for (i = 0; i < getSize(); ++i)
{
dupl = false;
for (n = 0; n < right.getSize(); ++n)
{
if ((*this)[i] == right[n])
{
dupl = true;
break;
}
}
if (dupl) continue; // skip duplicate in first array
temp[k] = (*this)[i];
k++;
}
// Now we know how many elements were in the 'sum' array
Array arr(k + right.getSize());
for (i = 0; i < k; ++i)
arr[i] = temp[i];
for (n = 0; n < right.getSize(); ++n,++k)
arr[k] = right[n];
return arr;
}
A further way to implement operator+ (for both the above definitions of addition) is to declare a friend global operator+ which takes two arguments:
class Array
{
...
public:
friend Array operator+(const Array & left, const Array & right);
...
};
You can implement it in Array.cpp though it is not a member of Array class but a global function:
// array.cpp
...
Array operator+(const Array & left, const Array & right)
{
....
}
The implementation is nearly identical to one of the above samples beside that (*this) must be replaced by left and all calls of getSize by left.getSize.
The subtraction only makes sense if you define substraction as to remove entries from the left array which are also in the right array. You could implement it similar to the second sample for operator+ by using a temporary array. In case you have a remove member function you can spare the temporary array but only make a copy of the left array and remove the entries which were in the right array as well.
>>>> const Array &Array::operator=( const Array &right )
I agree with evilrix that the return value should be non-const. As it is a temporary array only which only lives within the current scope, it actually makes less sense to make it const. You only would force the caller to make an (unnecessary) copy if he/she wants to work further with the array:
Array & a1 = a2 + a3; // wouldn't work if const Array return
(a1 + a2).append(0); // wouldn't work either
Array a = (a2 + a3) + a4; // wouldn't work either
No, returning a const here isn't well-defined and an annoyance.
>> No. The operator+ returns a new Array by Value.
Yes as it should and as I have already pointed out above where I state, "Note that you must return a copy of a new object because the standard + and - operators shouldn't modify the original objects".
However, I was refering to this comment you made...
">>>> const Array &Array::operator=( const Array &right )
I agree with evilrix that the return value should be non-const. As it is a temporary array only which only lives within the current scope"
Clearly, and operator=() should not return a temporary, it returns a reference to *this and, as we both agree, it should be non-const.
I think we are just talking at cross purposes, but I don't want to confuse aditya86b. :)
>>>> I agree with evilrix that the return value should be non-const.
Sorry, you are right. I was mixing up operator= and operator+ (and possibly have confused the asker).
It isn't quite easy to find an example where the const return of operator= does any harm though ...
(a.operator=(a1)).append(1
wouldn't compile but I don't know whether that is a statement of relevance ...
(a = a1).append(98765);
compiles if a is a non-const Array.
>> It isn't quite easy to find an example where the const return of operator= does any harm though
It's not so much harm as semantically incorrect in terms of it doesn't fit with the standard nor compiler synthesised operators and, as I point out, this could be problematic when writing generic code. That said, the problem it tries to address is reasonable; however, (a) is it really a problem? and (b) even if it is since you can still do it with integral and compiler synthesized types changing your own types to behave differently is just going to confuse.
So to sum up, I applaud the idea (I think, although I'd have to check, Scott Meyer advocates doing this, or something like it); however, personally I prefer my semantics consistent even if they aren't wholly correct :)
Business Accounts
Answer for Membership
by: evilrixPosted on 2009-04-27 at 23:59:02ID: 24248190
>> How can I add three more additional operators for the following program.
++-faq-lit e/operator - overloadi ng.html
courses/cs 11/materia l/cpp/donn ie/ cpp-ops .html
What operators? Added to what?
See if these links help.
Operator overloading
http://www.parashift.com/c
C++ Operator Overloading Guidelines
http://www.cs.caltech.edu/