Re: Operatr+ Updated
On Feb 19, 8:04 pm, Nephi Immortal <immortalne...@gmail.com> wrote:
I read the topic =96 "Error operator+ function=94 in the previous
thread. Other folks explained how to put three possible operator+
functions.
I wrote two versions of class A and class B. Both classes are
similar, but one data member of class B uses reference instead of
value.
I cannot use class A version. I am told not to use copy construc=
tor
function. If I do, then copy constructor will have undefined
behavior. I should always place it in private.
They said not to put const on any function's parameter if param=
eter
is built-in type such as int. Please clarify why I should not use
const? Const is necessary to prevent changing parameter and I always
create temporary local variable and copy const parameter to it.
Take a look at class A and class B. Compare both of them. Class=
B
is ideal to be helper class or proxy class.
You can write like
_Low_Byte Low_Byte()
and
_High_Byte High_Byte()
Both functions are in class A.
You can create two classes: _Low_Byte and _High_Byte. The class =
B is
inherited into _Low_Byte class and _High_Byte class. You need to
redefine operator=.
I do not need to post two classes since you understood what my co=
de
means.
I believe that class A is to be correct code design. What about
class B?
class A {
public:
explicit A( unsigned int data );
~A();
A( const A &right );
A &operator=( const A &right );
A &operator=( unsigned int data );
operator unsigned int();
This looks like an excellent decision: making the conversion
constructor explicit, then overriding operator=. On the other
hand, I'm just slightly sceptical about one thing: most of the
time when you implement a class, you want it's operators, and
not those of the built-in type, whenever the class is used. The
presence of a user defined conversion operator means that you
risk getting just the opposite. User defined conversion
operators tend to be very dangerous. (I believe C++0x allows
them to be declared explicit. This would alleviate most of the
danger.)
friend A operator+( const A &left, const A &right );
friend A operator+( const A &left, unsigned int right );
friend A operator+( unsigned int left, const A &right );
Just a nit, but if the operators aren't defined inline, why make
them friend?
friend A operator+=( const A &left, const A &right );
friend A operator+=( const A &left, unsigned int right );
friend A operator+=( unsigned int left, const A &right );
The usual convention is for the first to to be members, not
friends (although IMHO, there is a good argument for making them
non-members, but with a non-const left parameter). As for the
last, it's probably irrelevant, since the it is covered by the
builtin operator += and the conversion operator.
At any rate, += should modify it's left arguement, so passing it
a reference to const is out.
private:
unsigned int m_data;
};
A::A( unsigned int data ) : m_data( data ) {
}
A::~A() {
}
A::A( const A &right ) : m_data( right.m_data ) {
}
A &A::operator=( const A &right ) {
m_data = right.m_data;
return *this;
}
Given the definition of the last three, I'd just let the
compiler take care of them (with perhaps a comment saying that
the compiler provided defaults are used).
A &A::operator=( unsigned int data ) {
m_data = data;
return *this;
}
A::operator unsigned int() {
return m_data;
}
A operator+( const A &left, const A &right ) {
return A( left ) += right;
}
A operator+( const A &left, unsigned int right ) {
return A( left ) += right;
}
A operator+( unsigned int left, const A &right ) {
return left += A( right );
}
Given these definitions, why friend?
A operator+=( const A &left, const A &right ) {
A t( left );
t.m_data += right.m_data;
return t;
}
This is very dubious. A += operator which doesn't modify the
left argument? I'd call this operator overloading abuse, and
very, very poor design.
A operator+=( const A &left, unsigned int right ) {
A t( left );
t.m_data += right;
return t;
}
A operator+=( unsigned int left, const A &right ) {
A t( right );
t.m_data += left;
return t;
}
class B {
public:
explicit B( unsigned int &data );
~B();
B( const B &right );
B &operator=( const B &right );
B &operator=( unsigned int data );
operator unsigned int();
friend unsigned int operator+( const B &left, const B &right );
friend unsigned int operator+( const B &left, unsigned int right =
);
friend unsigned int operator+( unsigned int left, const B &right =
);
friend unsigned int operator+=( const B &left, const B &right )=
;
friend unsigned int operator+=( const B &left, unsigned int ri=
ght );
friend unsigned int operator+=( unsigned int left, const B &ri=
ght );
private:
unsigned int &m_data;
It's almost always an error to have a reference as a data
member. And I can't think of a single exception when the class
has value semantics, as is the case here. Value semantics imply
both copy and assignment, and that both have roughly the same
semantics. Which isn't possible with reference members.
};
B::B( unsigned int &data ) : m_data( data ) {
}
B::~B() {
}
B::B( const B &right ) : m_data( right.m_data ) {
}
B &B::operator=( const B &right ) {
m_data &= 0xFF00u;
m_data |= ( right.m_data & 0xFFu );
return *this;
}
Note that this could have very undesirable semantics because of
the reference member. You could end up modifying the value of
right.
--
James Kanze