C / C++ / MFC

Re: Compiler generated assignment operator= question

10-Jun-03 9:32

Suppose I have a class with a few member variables, and one of them is a CArray object, e.g.:

CMyClass {
...
private:
  int var1, var2, var3;
  bool flag1, flag2, flag3;
  CArray <int,int&> arSomeArray;
};

If I didn't have that CArray member, I could simply write:

CMyClass a, b;
a = b;

The assignment operator would be simply generated by compiler. But when CArray is there, compiler cannot generate default assigment operator, so I have to add to the class:

CMyClass& operator= (CMyClass& src){
  var1 = src.var1;
  var2 = src.var2;
  var3 = src.var3;
  flag1 = src.flag1;
  flag2 = src.flag2;
  flag3 = src.flag3;
  arSomArray.Copy (src.arSomeArray);
  return *this;
}

Not only that it is very tedious writing a few dozen of "x = src.x", it is also prone to bugs. Like later I will add a variable to the class and might forget to add it to the operator= function.

Is there a way to write something like below?

CMyClass& operator= (CMyClass& src){
  dear_compiler_do_what_you_can_with_all_the_variables_i_ll_take_care_of_the_rest();
  arSomArray.Copy (src.arSomeArray);
  return *this;
}

Thanks

Ryan_Roberts10-Jun-03 9:38

Ryan_Roberts

10-Jun-03 9:38

Not using CArray would be a good start Big Grin | :-D

MFC's container classes suck. Try using a stl container instead, it might just change your life.

Ryan

Re: Compiler generated assignment operator= question

John M. Drescher10-Jun-03 9:51

Re: Compiler generated assignment operator= question

10-Jun-03 9:51

I agree 100%. I've used the MFC containers for years but STL is much more powerful and more portable. I wish I switched a long time ago. Try std::vector

John

Damir Valiulin10-Jun-03 10:12

Re: Compiler generated assignment operator= question

10-Jun-03 10:12

Thanks, but I am not going to rewrite a few hundred of classes, possibly breaking several projects along the way, just for this cause.

Having CArray with all its upsides and downsides is a must.

John M. Drescher10-Jun-03 10:18

Re: Compiler generated assignment operator= question

10-Jun-03 10:18

I know what you mean. I have a lot of code in several DLLs that sill has MFC containers and in most cases it is better not to rewrite but I wish I would have known stl in the first place. Anything new I will use stl containers instead of MFC.

John

Dave Bryant10-Jun-03 10:00

Dave Bryant

10-Jun-03 10:00

You could declare all the members you want automatically copied in a structure defined within the class - C++ will then generate an assignment operator for that structure.

e.g.

class Blah
{
private:
  struct Hidden
  {
    int a;
    int b;
  };

  Hidden h;
  CArray<int,int> array;

  Blah& operator=(const Blah& copy)
  {
    h = copy.h;
    // Copy the array...
  }
};

However, as others have pointed out, if you use STL you don't run into these problems.

Dave
http://www.cloudsofheaven.org

Re: Compiler generated assignment operator= question

Damir Valiulin10-Jun-03 10:21

Re: Compiler generated assignment operator= question

10-Jun-03 10:21

The idea is good, however separating some variables into a structure just for coding convinience would not make sense to someoneelse reading the code.

Dave Bryant10-Jun-03 10:24

Dave Bryant

10-Jun-03 10:24

I agree it would look weird and non-intuative - which is while i recommend STL.

Dave
http://www.cloudsofheaven.org

Re: Compiler generated assignment operator= question

Dean Goodman10-Jun-03 10:21

Dean Goodman

10-Jun-03 10:21

What about writing a quick subclass of CArray that defines operator= and simply calls CArray::Copy()? That would still be compatible with your other class that just use CArray.

--Dean

Re: Compiler generated assignment operator= question

Damir Valiulin10-Jun-03 11:58

Re: Compiler generated assignment operator= question

10-Jun-03 11:58

Thank you. This is exactly the answer I was looking for!

I derived a class from CArray and added operator= to it. Now compiler has no trouble generating default assignment. Everything works perfectly! Big Grin | :-D

John M. Drescher10-Jun-03 10:34

Re: Compiler generated assignment operator= question

10-Jun-03 10:34

There is a problem in your assignment operator. If someone assigns an object to itself your code will fail on dynamic data such as CArray. For example:

CMyClass A;

A=A;

//What happens to arSomArray?

To solve this I create a private destroy() and copy() functions and implement the copy constructor and assignment operator as follows:

PROPERTY::~PROPERTY()
{
destroy();
}

PROPERTY::PROPERTY(PROPERTY & other )
{
copy(other);
}

PROPERTY& PROPERTY::operator =(PROPERTY & other )
{
if ( &other != this ) {
destroy();
copy( other );
}
return *this;
}

copy() does the copy of data from one class to the other similar to what you did in your assignment operator

destroy() deletes any dynamically allocated data.

I have an idea to solve your problem that I will post a little bit later.

John

Damir Valiulin10-Jun-03 11:55

Re: Compiler generated assignment operator= question

10-Jun-03 11:55

Thank you for the reminder. I remember I've read some article on CodeProject about dangers of CArray such assigning to itself or from reference to itself. I will keep this in mind.

As for the answer to my problem, Dean Goodman already answered it.

John M. Drescher10-Jun-03 13:14

10-Jun-03 13:14

I was just writing some code for my idea... Anyways make sure you provide a copy constructor otherwise the complier would provide one and circumvent your code for the following code

CMyClass a;

CMyClass b = a;

This code will not call the = operator. It uses the copy constructor...

John

Serialize()

RubenJ10-Jun-03 9:23

RubenJ

10-Jun-03 9:23

I’m using the serialize() function to save and open data and it works fine within the program. But when I try to open “myFile.txt” with Notepad the characters are not recognizable. Does anyone know what is happening? What do I have to do to make the file readable in Notepad? Below is the code I wrote.

Thanks,
Ruben

void CMyDlg::OnButtonSave() <br />
{<br />
	// Create a file <br />
	CFile myFile("c:\\myfile.txt", CFile::modeCreate | CFile::modeReadWrite);<br />
<br />
	// Create a storing archive.<br />
	CArchive arStore(&myFile, CArchive::store);<br />
<br />
	// Call serialize<br />
	CMyDlg::Serialize(arStore);<br />
<br />
	// Close the storing archive.<br />
	arStore.Close();<br />
}<br />
<br />
void CMyDlg::Serialize(CArchive& ar) <br />
{<br />
	CString str;<br />
	<br />
	if (ar.IsStoring())<br />
	{	// storing code<br />
str.Format("This is a line");<br />
		ar << str;<br />
	}<br />
	else<br />
	{	// loading code<br />
		ar >> str;<br />
	}	<br />
}<br />
<br />
void CMyDlg::OnButtonOpen() <br />
{<br />
	// Open the file<br />
	CFile myFile("c:\\myfile.txt", CFile::modeReadWrite);<br />
<br />
	// Create a loading archive.<br />
	myFile.SeekToBegin();<br />
	CArchive arLoad(&myFile, CArchive::load);<br />
<br />
	// Call serialize<br />
	CMyDlg::Serialize(arLoad);<br />
<br />
	// Close the file<br />
	arLoad.Close();<br />
}

John M. Drescher10-Jun-03 9:27

10-Jun-03 9:27

Serialize stores the data in a binary format.

John

RubenJ10-Jun-03 10:36

RubenJ

10-Jun-03 10:36

So I will have to use fstream in order to be able to see the data externally?

Ruben

Navin10-Jun-03 10:51

Navin

10-Jun-03 10:51

Yep. You're probably better off doing it that way, anyway.

"When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert Einstein