Click here to Skip to main content
14,872,699 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
some where written that we use our custom copy constructor for copy dynamic memory allocation because default copy constructor copy the simple data members but if the member variable is a pointer in this case the default constructor can copy only the pointer but can't copy where the pointer is pointing to.is it right or wrong? describe me briefly please.
Posted
Updated 18-Jan-11 9:56am
v3

In a couple of projects, I have had to build custom "copy constructors" which had to take into account special cases for internal member variable values. I couldn't really give you a definitive case where I used it because I have been at least a couple of years removed from that project.

My rule of thumb would be that built-in behavior should always be used unless there is a special case that warrants a custom solution.

[edit] I missed that you were working with CLI. Please note that my answer, although reasonable relevant, is based on unmanaged code.
   
v2
Comments
Nish Nishant 18-Jan-11 15:15pm
   
Marcus, the OP has tagged the thread with C++/CLI, and in C++/CLI copy constructors are not auto generated for managed types.
fjdiewornncalwe 18-Jan-11 15:41pm
   
Good catch.. I missed the CLI part.
Nish Nishant 18-Jan-11 16:03pm
   
Well the OP has re-tagged his question with C++ now and not C++/CLI. So your answer holds now. And I'll vote it a 5!
fjdiewornncalwe 18-Jan-11 16:41pm
   
Moving targets are so much more fun to try to hit, aren't they.
Espen Harlinn 18-Jan-11 17:26pm
   
5+ Good answer Marcus
Alternate answer (posted after the OP re-tagged his post with C++)

Okay, with native code it is as you understand it. The default copy ctor will just copy the pointer members over so that the object's copy will have member pointers that are pointing to the same objects as the original's members are.

It's purely a design consideration whether this is desirable or not. Some designs may warrant a shallow copy, others may absolutely require a deep copy. When you need to have full control of how this copy works, you need to add your own copy constructors.
   
v2
Comments
Espen Harlinn 18-Jan-11 17:25pm
   
Sums it up
See this sample chapter from my book:

http://www.manning.com/sivakumar/sample-ch01_sivakumar.pdf[^]

Scroll down to section 1.5.3 on Copy constructors.
   
Comments
CPallini 18-Jan-11 14:58pm
   
'See this sample chapter from my book' - Few people can write a sentence like that. My 5. :-)
Nish Nishant 18-Jan-11 15:01pm
   
Okay, I didn't mean to sound it like that. Now that I re-read it, yes it does sound a tad arrogant. Sorry about that. :-)
Nish Nishant 18-Jan-11 15:08pm
   
Holy cow, a Platinum guy down voted me :-)
fjdiewornncalwe 18-Jan-11 15:13pm
   
Without mentioning that it is yours, you could just say... "Look at this super-awesome chapter here" :).
Nish Nishant 18-Jan-11 15:15pm
   
Yeah, I should have done that :-)
CPallini 18-Jan-11 15:32pm
   
I didn't mean that. I didn't (and I don't)think that. Mine is sincere admiration. :-)
Nish Nishant 18-Jan-11 15:33pm
   
LOL. Thank you :-)
Espen Harlinn 18-Jan-11 15:33pm
   
Nice chapter, nothing wrong with referring to you own work - especially when it's this thorough (5+)
Nish Nishant 18-Jan-11 15:34pm
   
Heh - thanks :-)
Espen Harlinn 18-Jan-11 15:57pm
   
I've read it through - good work, hope you are making a bundle :)
Nish Nishant 18-Jan-11 16:02pm
   
Let's just put it this way, I am still driving the same class car and eating at the same class restaurants I used to before the book was out. *grin*

Of course it didn't help that the VC++ team decided not to push C++/CLI in VS 2010.
Espen Harlinn 18-Jan-11 16:21pm
   
So far I'm quite happy with VC++ 2010, why they are not pushing the technology is a mystery. Lately I've played a bit around with c++/cli, I'm actually a bit surprised at how well mixed mode works.
Nish Nishant 18-Jan-11 16:24pm
   
I guess it's mostly because the number of folks using C++/CLI for interop was far smaller than the number of people using P/Invoke or COM interop.
Espen Harlinn 18-Jan-11 16:35pm
   
Even if it makes the job more complicated :)
I never use the default copy constructor and often declare it private and do not define it. In some classes, I never want to use a copy constructor. Using the default copy constructor makes it easier to make programming bugs inadvertently and makes shallow instead of deep copies.
   
Say you have the class
class MyString {
	public:
		MyString() {
			m_szTheString = NULL;
		}
		MyString(const char *szString) {
			size_t nLen = strlen(szString) + 1;
			m_szTheString = new char[nLen];
			memcpy(m_szTheString, szString, nLen);
		}
		~MyString() {
			if (m_szTheString != NULL) {
				delete []m_szTheString;
			}
		}
	//Functions that are irrelevant to this sample
	//...
	private:
		char *m_szTheString;
};


This is using the default copy constructor.
if we look at this class in memory, it takes 4 (or 8 on 64 bit) bytes of memory, to store the pointer to the string held in m_szTheString.

Then the default copy constructor does what is called a "shallow copy", that is copy the memory from 1 instance to the other. Think of it like this:
MyString strA("hello");
MyString strB(strA); //copies the 4 bytes for the pointer

is (conceptually) equivelent to
MyString strA("hello");
MyString strB();
memcpy(&strB, &strA, sizeof(MyString)); //copies the 4 bytes for the pointer


This means that both classes now have a pointer to the same memory address (the actual string), so if 1 of the objects changes the string, then it changes in the other 1 too.

By using your own copy constructor you can make a copy of the memory referanced too.
MyString(const MyString &strOther) {
	//The default would be equivelent to: m_szTheString = strOther.m_szTheString;
	size_t nLen = strlen(strOther.m_szTheString) + 1;
	m_szTheString = new char[nLen];
	memcpy(m_szTheString, szString, nLen);
}
   

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)




CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900