<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: 9.12 &#8212; Shallow vs. deep copying</title>
	<atom:link href="http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/</link>
	<description></description>
	<pubDate>Fri, 29 Aug 2008 19:36:56 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Learn C++ - &#187; 9.11 &#8212; The copy constructor and overloading the assignment operator</title>
		<link>http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-14412</link>
		<dc:creator>Learn C++ - &#187; 9.11 &#8212; The copy constructor and overloading the assignment operator</dc:creator>
		<pubDate>Mon, 05 May 2008 02:11:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-14412</guid>
		<description>[...] 2007      Prev/Next Posts   &#171; 9.10 &#8212; Overloading typecasts &#124; Home &#124; 9.12 &#8212; Shallow vs. deep copying &#187;     Sunday, November 4th, 2007 at 8:52 [...]</description>
		<content:encoded><![CDATA[<p>[...] 2007      Prev/Next Posts   &laquo; 9.10 &#8212; Overloading typecasts | Home | 9.12 &#8212; Shallow vs. deep copying &raquo;     Sunday, November 4th, 2007 at 8:52 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tom</title>
		<link>http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-11147</link>
		<dc:creator>Tom</dc:creator>
		<pubDate>Mon, 07 Apr 2008 15:26:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-11147</guid>
		<description>Hello Alex -

In the code box after the paragraph that begins with the sentence "Now letâ€™s do the overloaded assignment operator.", I think line 1 of the code should be:

&lt;pre&gt;

01. // Assignment operator 
&lt;/pre&gt;

Not:

&lt;pre&gt;
01. // Copy constructor
&lt;/pre&gt;

Thanks.

[ Good eye.  Fixed!  Thanks.  -Alex ]</description>
		<content:encoded><![CDATA[<p>Hello Alex -</p>
<p>In the code box after the paragraph that begins with the sentence &#8220;Now letâ€™s do the overloaded assignment operator.&#8221;, I think line 1 of the code should be:</p>
<pre>

01. // Assignment operator
</pre>
<p>Not:</p>
<pre>
01. // Copy constructor
</pre>
<p>Thanks.</p>
<p>[ Good eye.  Fixed!  Thanks.  -Alex ]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alex</title>
		<link>http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-7299</link>
		<dc:creator>Alex</dc:creator>
		<pubDate>Tue, 05 Feb 2008 18:18:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-7299</guid>
		<description>The way the above code without the self-assignment check is written, the program won't crash (it just produces an unexpectedly incorrect result, which in some ways can be worse).  I changed the wording of the text to be more accurate in that regard.  However, any time you are dealing with a pointer to unallocated memory, you are "living on the edge" so to speak and are just begging for a crash, corrupted memory, or some other bit of nastiness to happen.

I should be slightly more clear about my terminology -- when I said "valid memory address" in the above comment, I really meant "allocated memory address".  Also, to be a bit more clear, accessing an unassigned bit of memory won't necessarily cause a crash.  It may or it may not, depending on where the piece of memory is and whether the operating system has protected that memory.  Windows, for example, prevents programs from reading and writing to certain memory addresses in order to prevent malicious code from overwriting parts of the operating system.  If you try to do that, you will get an access violation.

For example, consider the following program:
&lt;pre&gt;
// Assign some memory to pnValue
int *pnValue = new int;
// Write a value into that memory.  This is fine
*pnValue = 6;
// Delete the memory
delete pnValue;

// The following is not a good idea, but it probably
// won't crash
cout &lt;&lt; *pnValue;

// Now, let's set the pointer to a protected address
pnValue = (int*)0xFFFFFFFF;

// This will definitely crash
cout &lt;&lt; *pnValue;
&lt;/pre&gt;</description>
		<content:encoded><![CDATA[<p>The way the above code without the self-assignment check is written, the program won&#8217;t crash (it just produces an unexpectedly incorrect result, which in some ways can be worse).  I changed the wording of the text to be more accurate in that regard.  However, any time you are dealing with a pointer to unallocated memory, you are &#8220;living on the edge&#8221; so to speak and are just begging for a crash, corrupted memory, or some other bit of nastiness to happen.</p>
<p>I should be slightly more clear about my terminology &#8212; when I said &#8220;valid memory address&#8221; in the above comment, I really meant &#8220;allocated memory address&#8221;.  Also, to be a bit more clear, accessing an unassigned bit of memory won&#8217;t necessarily cause a crash.  It may or it may not, depending on where the piece of memory is and whether the operating system has protected that memory.  Windows, for example, prevents programs from reading and writing to certain memory addresses in order to prevent malicious code from overwriting parts of the operating system.  If you try to do that, you will get an access violation.</p>
<p>For example, consider the following program:</p>
<pre>
// Assign some memory to pnValue
int *pnValue = new int;
// Write a value into that memory.  This is fine
*pnValue = 6;
// Delete the memory
delete pnValue;

// The following is not a good idea, but it probably
// won't crash
cout < < *pnValue;

// Now, let's set the pointer to a protected address
pnValue = (int*)0xFFFFFFFF;

// This will definitely crash
cout << *pnValue;
</pre>
</pre>
]]></content:encoded>
	</item>
	<item>
		<title>By: Zafer</title>
		<link>http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-7294</link>
		<dc:creator>Zafer</dc:creator>
		<pubDate>Tue, 05 Feb 2008 17:15:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-7294</guid>
		<description>In that case how can the program crash? Also, it's still counterintuitive for a pointer not to contain a valid memory address but point to some garbage region and be copiable.</description>
		<content:encoded><![CDATA[<p>In that case how can the program crash? Also, it&#8217;s still counterintuitive for a pointer not to contain a valid memory address but point to some garbage region and be copiable.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alex</title>
		<link>http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-7291</link>
		<dc:creator>Alex</dc:creator>
		<pubDate>Tue, 05 Feb 2008 16:37:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-7291</guid>
		<description>In the last example, we omitted the check for self-assignment.  This means that if the user does a self-assignment, m_pchString will equal cString.m_pchString.  When we delete m_pchString, we will also delete cString.m_pchString.

When we delete a pointer using delete or delete[], it does not contain a valid memory address any longer.  However, that does not necessarily mean the program will crash if you use the pointer for reading.

Consequently, in the last example, the if statement will succeed because cString.m_pchString is non-zero.  It will then allocate new memory for m_pchString (and cSource.m_pchString).  Then it copies cSource.m_pchString, which is that uninitialized new memory (aka. garbage) into m_pchString, which is itself.

The end result of the self-assignment without the self-assignment check is that you'll get a new string of the correct length, but it will be filled with garbage.</description>
		<content:encoded><![CDATA[<p>In the last example, we omitted the check for self-assignment.  This means that if the user does a self-assignment, m_pchString will equal cString.m_pchString.  When we delete m_pchString, we will also delete cString.m_pchString.</p>
<p>When we delete a pointer using delete or delete[], it does not contain a valid memory address any longer.  However, that does not necessarily mean the program will crash if you use the pointer for reading.</p>
<p>Consequently, in the last example, the if statement will succeed because cString.m_pchString is non-zero.  It will then allocate new memory for m_pchString (and cSource.m_pchString).  Then it copies cSource.m_pchString, which is that uninitialized new memory (aka. garbage) into m_pchString, which is itself.</p>
<p>The end result of the self-assignment without the self-assignment check is that you&#8217;ll get a new string of the correct length, but it will be filled with garbage.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Zafer</title>
		<link>http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-7288</link>
		<dc:creator>Zafer</dc:creator>
		<pubDate>Tue, 05 Feb 2008 15:42:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-7288</guid>
		<description>In the last example, when we say delete [] m_pchString, the program is likely to crash because of 

if (cSource.m_pchString)

or 

strncpy(m_pchString, cSource.m_pchString, m_nLength)?

When we delete a pointer using delete [], does it still contain a valid memory address?</description>
		<content:encoded><![CDATA[<p>In the last example, when we say delete [] m_pchString, the program is likely to crash because of </p>
<p>if (cSource.m_pchString)</p>
<p>or </p>
<p>strncpy(m_pchString, cSource.m_pchString, m_nLength)?</p>
<p>When we delete a pointer using delete [], does it still contain a valid memory address?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: test</title>
		<link>http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-6921</link>
		<dc:creator>test</dc:creator>
		<pubDate>Thu, 31 Jan 2008 08:06:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-6921</guid>
		<description>"// Problematic copy constructor" ==&gt; "//Problematic assigment operator"?

[ Fixed!  Thanks.  -Alex ]</description>
		<content:encoded><![CDATA[<p>&#8220;// Problematic copy constructor&#8221; ==> &#8220;//Problematic assigment operator&#8221;?</p>
<p>[ Fixed!  Thanks.  -Alex ]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sergk</title>
		<link>http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-2616</link>
		<dc:creator>sergk</dc:creator>
		<pubDate>Sat, 10 Nov 2007 12:22:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.learncpp.com/cpp-tutorial/912-shallow-vs-deep-copying/#comment-2616</guid>
		<description>I'd like to note, to avoid problems with inherited classes, one have to make destructor and assignment operators to be virtual.

-- serg.</description>
		<content:encoded><![CDATA[<p>I&#8217;d like to note, to avoid problems with inherited classes, one have to make destructor and assignment operators to be virtual.</p>
<p>&#8211; serg.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
