question on the assignment operator

[ma740988]

Consider:

# include <iostream>
# include <algorithm>
# include <vector>
# include <string>
using namespace std;

class msg {
std::string someStr;
public:
msg(const std::string& sStr)
: someStr(sStr) {}
msg( const msg& rhs )
: someStr(rhs.som eStr)
{}
void swap( msg& rhs ) {
std::swap( someStr, rhs.someStr );
}
msg& operator=( const msg& rhs) {
msg tmp (rhs);
swap(tmp);
return *this;
}
std::string get_some_str() const { return someStr; }
};

class Y {
typedef std::vector<msg > msgVec;
msgVec msg_vec;
public:
Y(){}
Y( const Y& rhs )
: msg_vec(rhs.msg _vec)
{}
void swap( Y& rhs ) {
std::swap( msg_vec, rhs.msg_vec );
}
Y& operator=( const Y& rhs) {
Y tmp (rhs);
swap(tmp);
return *this;
}
void add(msg& ms)
{ msg_vec.push_ba ck(ms); }

void print()
{
if (msg_vec.size() )
std::cout << msg_vec[0].get_some_str() << std::endl; // just for
test
}

};

class Controller {
typedef std::vector<Y> VEC_Y;
VEC_Y vectorOfYs;
public:

Controller() {}
Controller( const Controller& rhs )
: vectorOfYs(rhs. vectorOfYs)
{}

void swap( Controller& rhs ) {
std::swap( vectorOfYs, rhs.vectorOfYs );
}
Controller& operator=( const Controller& rhs) {
Controller tmp (rhs);
swap(tmp);
return *this;
}

void add_y(Y myY)
{ vectorOfYs.push _back(myY);}

void add_msg ( msg& ms )
{
if (vectorOfYs.siz e())
vectorOfYs[0].add(ms); // brute force for test.
}
void print() {
if (vectorOfYs.siz e())
vectorOfYs[0].print(); // just experimenting
}
};

int main()
{
Controller ctrl1;
ctrl1.add_y(Y() );
ctrl1.add_msg(m sg("test"));

Controller ctrl2;
ctrl2 = ctrl1;
ctrl2.print();
}
For assignment between two controller objects, the fact that the class
Controller contains a vector of Y's which in turn contains a vector of
msg's; implies that theres - perhaps a requirement for a copy
constructor in all _three_ classes. Correct?

[Victor Bazarov]

ma740988 wrote:

Consider:

# include <iostream>
# include <algorithm>
# include <vector>
# include <string>
using namespace std;

class msg {
std::string someStr;
public:
msg(const std::string& sStr)
: someStr(sStr) {}
msg( const msg& rhs )
: someStr(rhs.som eStr)
{}
void swap( msg& rhs ) {
std::swap( someStr, rhs.someStr );
}
msg& operator=( const msg& rhs) {
msg tmp (rhs);
swap(tmp);
return *this;
Really? No, REALLY? Why not simply

someStr = rhs.someStr;
return *this;

?
}
std::string get_some_str() const { return someStr; }
};

class Y {
typedef std::vector<msg > msgVec;
msgVec msg_vec;
public:
Y(){}
Y( const Y& rhs )
: msg_vec(rhs.msg _vec)
{}
void swap( Y& rhs ) {
std::swap( msg_vec, rhs.msg_vec );
}
Y& operator=( const Y& rhs) {
Y tmp (rhs);
swap(tmp);
Again... WHY? Just assign:

msg_vec = rhs.msg_vec;
return *this;
}
void add(msg& ms)
void add(msg const & ms) // a bit better
{ msg_vec.push_ba ck(ms); }

void print()
{
if (msg_vec.size() )
std::cout << msg_vec[0].get_some_str() << std::endl; // just for
test
}

};

class Controller {
typedef std::vector<Y> VEC_Y;
VEC_Y vectorOfYs;
public:

Controller() {}
Controller( const Controller& rhs )
: vectorOfYs(rhs. vectorOfYs)
{}

void swap( Controller& rhs ) {
std::swap( vectorOfYs, rhs.vectorOfYs );
}
Controller& operator=( const Controller& rhs) {
Controller tmp (rhs);
swap(tmp);
<sigh>...
return *this;
}

void add_y(Y myY)
void add_y(Y const & myY)
{ vectorOfYs.push _back(myY);}

void add_msg ( msg& ms )
{
if (vectorOfYs.siz e())
if (!vectorOfYs.em pty()) // better
vectorOfYs[0].add(ms); // brute force for test.
}
void print() {
if (vectorOfYs.siz e())
if (!vectorOfYs.em pty()) // better
vectorOfYs[0].print(); // just experimenting
}
};

int main()
{
Controller ctrl1;
ctrl1.add_y(Y() );
ctrl1.add_msg(m sg("test"));

Controller ctrl2;
ctrl2 = ctrl1;
ctrl2.print();
}
For assignment between two controller objects, the fact that the class
Controller contains a vector of Y's which in turn contains a vector of
msg's; implies that theres - perhaps a requirement for a copy
constructor in all _three_ classes. Correct?

No, not really. Since none of those objects require any special
processing during copy-construction, the compiler-generated one
is just right.

Besides, why are you doing all this nonsense in the assignment
operators? Simply assign the damn members and move on to more
important things...

V

[Ali Çehreli]

"Victor Bazarov" <v.********@com Acast.net> wrote in message
news:a4******** *************** *******@comcast .com...

ma740988 wrote:

Consider:

# include <iostream>
# include <algorithm>
# include <vector>
# include <string>
using namespace std;

class msg {
std::string someStr;
public:
msg(const std::string& sStr)
: someStr(sStr) {}
msg( const msg& rhs )
: someStr(rhs.som eStr)
{}
void swap( msg& rhs ) {
std::swap( someStr, rhs.someStr );
}
msg& operator=( const msg& rhs) {
msg tmp (rhs);
swap(tmp);
return *this;
Really? No, REALLY? Why not simply

someStr = rhs.someStr;
return *this;

Even further, why define operator= at all? Defining operator= unnecessarily
opens the risk of forgetting to assign any members that may be added in the
future. Forgetting to assign the base classes is another problem that I've
lived in the past.

[...]
No, not really. Since none of those objects require any special
processing during copy-construction, the compiler-generated one
is just right.
Agreed... I wanted to add operator=; because it should get the same
treatment as the copy constructor here :)
Besides, why are you doing all this nonsense in the assignment
operators? Simply assign the damn members and move on to more
important things...

Now I am beginning to suspect that there may be something special about
operator=. You agree that the compiler generated operator= is just right,
right? :)

Ali

[Jacek Dziedzic]

Victor Bazarov wrote:

[...]

Besides, why are you doing all this nonsense in the assignment
operators? Simply assign the damn members and move on to more
important things...

To quote Sutter and Alexandrescu:
"It is often beneficient to use the swap function in the
assignment operator. The below mentioned implementation gives
strong reliability, although at the price of constructing an
extra object. If speed matters it should not be used"

T& T::operator=(co nst T& other) {
T temp(other);
swap(temp);
return *this;
}

So, if I understand correctly it means that if you make
the swap operation and the copy ctor unfailible (they don't
throw) that makes your assignment operator unfailible too.

That said, I think calling it "nonsense" is rather
strong worded.

Someone correct me if I'm wrong -- I only read the book
last week :)

cheers,
- J.

[Ali Çehreli]

"Jacek Dziedzic" <jacek@no_spam. tygrys.no_spam. net> wrote in message
news:72******** *************** ***@news.chello .pl...

Victor Bazarov wrote:

[...]

Besides, why are you doing all this nonsense in the assignment
operators? Simply assign the damn members and move on to more
important things...
To quote Sutter and Alexandrescu:
"It is often beneficient to use the swap function in the
assignment operator. The below mentioned implementation gives
strong reliability, although at the price of constructing an
extra object. If speed matters it should not be used"

T& T::operator=(co nst T& other) {
T temp(other);
swap(temp);
return *this;
}

Though uncommon but even better implementation is:

T& T::operator=(T temp) // <-- note the copy
{
swap(temp);
return *this;
}

That version gives the compiler more help in optimizations.
So, if I understand correctly it means that if you make
the swap operation and the copy ctor unfailible (they don't
throw) that makes your assignment operator unfailible too.

No, only the swap needs to be non-throwing, and better be fast too (usually
is). Copy constructor can throw... The good thing is that, even if the copy
constructor throws, the state of the current object (the destination) is
unchanged. That is the power of doing the actual work on the side before
changing the state by non-throwing operations (swap in this case).

If additionally the copy constructor does not throw, then operator= does not
throw either.

Ali

[Jacek Dziedzic]

Ali Çehreli wrote:

[...]
Though uncommon but even better implementation is:

T& T::operator=(T temp) // <-- note the copy
{
swap(temp);
return *this;
}

That version gives the compiler more help in optimizations.

Yep, that's what they mention on the next page :).

So, if I understand correctly it means that if you make
the swap operation and the copy ctor unfailible (they don't
throw) that makes your assignment operator unfailible too.

No, only the swap needs to be non-throwing, and better be fast too
(usually is). Copy constructor can throw... The good thing is that, even
if the copy constructor throws, the state of the current object (the
destination) is unchanged. That is the power of doing the actual work on
the side before changing the state by non-throwing operations (swap in
this case).

If additionally the copy constructor does not throw, then operator= does
not throw either.

Ah, thanks for the clarification!

cheers,
- J.

[ma740988]

>

Again... WHY? Just assign:

That's the preferred approach if I recall correctly from - I believe -
Sutter 's text.

For assignment between two controller objects, the fact that the class
Controller contains a vector of Y's which in turn contains a vector of
msg's; implies that theres - perhaps a requirement for a copy
constructor in all _three_ classes. Correct?

No, not really. Since none of those objects require any special
processing during copy-construction, the compiler-generated one
is just right.

Actually, what I should have shown was an example were the msg class
dynamically allocated memory. In that case only the _msg_ class would
require an assignment operator?

[Victor Bazarov]

ma740988 wrote:

Again... WHY? Just assign:

That's the preferred approach if I recall correctly from - I believe -
Sutter 's text.

Any justification for it that you actually understand? Following
somebody's "text" blindly has lead humanity to many a perils.

For assignment between two controller objects, the fact that the
class Controller contains a vector of Y's which in turn contains a
vector of msg's; implies that theres - perhaps a requirement for a
copy constructor in all _three_ classes. Correct?

No, not really. Since none of those objects require any special
processing during copy-construction, the compiler-generated one
is just right.

Actually, what I should have shown was an example were the msg class
dynamically allocated memory. In that case only the _msg_ class would
require an assignment operator?

See "the Rule of Three".

V

[ma740988]

Any justification for it that you actually understand? Following
somebody's "text" blindly has lead humanity to many a perils. :)
See "the Rule of Three".

Right and that I know. I was trying to get a feel for the impact with
regards to class A, B and C. B has a vector of A and C has a vector of
B. I think I understand now, in that - for the scenario, I
highlighted in my initial post. if class msg dynamically allocated
memory, then class msg should provided the operator=, etc and that
would be all I need even though I'm assigning 'controller' objects.

Thanks

[Ali Çehreli]

"Victor Bazarov" <v.********@com Acast.net> wrote in message
news:H7******** ************@co mcast.com...

ma740988 wrote:

See "the Rule of Three".

The rule of three can be understood, as I've done in the past, as "don't
define operator= if the class consists only of members that take care of
themselves."

With "taking care of themselves," I mean classes that define proper copy
constructors and assignment operators, which work correctly. Further, let's
take "working correctly" here as copying and assigning successfully.
Propagating exceptions should be fine too, if the object is left in a
consistent state. For example, std::string is such a class.

If one applies the guidelines as above, and believes that their class will
work correctly even if a member's operator= can throw, they might be dealing
with corrupt objects.

I think that the rule of three must go with an addition:

- Observe the rule of three (If any one of the three special functions needs
to be defined, chances are you will have to at least declare the other two)

- Additionally, if you want your objects be in a consistent state if a
member throws, always define operator=.

I've run a simple program to analyze what happens during the execution of
operator= when different operations throw or not and when operator= is
implicit or explicit.

A: a class without any members
B: a class that contains two std::strings and an A that is deliberately
defined between two strings

class B
{
string first_;
A a_;
string last_;

/* ... */
};

The legend for the table below:

completes: The operation completes successfully
throws: The operation is interrupted with an exception
implicit: The compiler generated operator= is used
explicit: operator= is defined by the user
new: The object gets the new state
old: The object is left in the old state
corrupt: The state of the object is corrupt

The results are:

A::A(A) A::operator=(A) B::operator=(B) | B's state
------------------------------------------------------|------------
completes completes implicit | new
throws completes implicit | new
completes throws implicit | corrupt
throws throws implicit | corrupt
completes completes explicit | new
throws completes explicit | old
completes throws explicit | new
throws throws explicit | old

What I digest from these results is:

1) If you leave operator= to the compiler (implicit) you may end up with a
corrupt object if operator= of a member throws

2) If you define operator= yourself (explicit) you may be left with the old
state

3) Otherwise you will get the new state

As a result, operator= is even more special that the other two, in that, it
prevents having an inconsistent object.

Here is the program I used to test these:

#include <iostream>
#include <string>

using namespace std;

// Comment-out or keep combinations of these macros to see the
// behavior for each case
// #define A_COPY_THROWS
// #define A_ASSIGNMENT_TH ROWS
// #define B_ASSIGNMENT_EX PLICIT

class A
{
public:

A()
{}

#if defined(A_COPY_ THROWS)
A(A const &)
{
throw 42;
}
#endif

#if defined(A_ASSIG NMENT_THROWS)
A & operator= (A const &)
{
throw 42;
}
#endif

void swap(A & other)
{}
};

class B
{
string first_;
A a_;
string last_;

friend ostream & operator<< (ostream &, B const &);

public:

explicit B(string const & value)
:
first_(value),
last_(value)
{}

bool operator== (B const & other) const
{
return ((first_ == other.first_)
&&
(last_ == other.last_));
}

#if defined(B_ASSIG NMENT_EXPLICIT)
B & operator= (B temp)
{
swap(temp);
return *this;
}
#endif

void swap(B & other)
{
first_.swap(oth er.first_);
a_.swap(other.a _);
last_.swap(othe r.last_);
}
};

ostream & operator<< (ostream & os, B const & b)
{
return os << b.first_ << ' ' << b.last_;
}

bool check_B_invaria nt(string const & label, B const & lhs, B const & rhs)
{
cout << label << ": ";

cout << "comparing " << lhs << " with " << rhs << '\n';

if ( ! (lhs == rhs))
{
cout << "NO ";
}

cout << "match\n";
}

int main()
{
B zero("0");
B b0("0");
B b1("1");

check_B_invaria nt("before", zero, b0);

try
{
b0 = b1;
check_B_invaria nt("completed" , b0, b1);
}
catch (...)
{
check_B_invaria nt("caught exception", b0, zero);
}
}
Ali