<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Memory-Management on Karpoke - Just Another Blog</title><link>http://karpoke.ignaciocano.com/tags/memory-management/</link><description>Recent content in Memory-Management on Karpoke - Just Another Blog</description><generator>Hugo -- 0.167.0</generator><language>es</language><lastBuildDate>Sun, 18 Jan 2015 10:59:00 +0100</lastBuildDate><atom:link href="http://karpoke.ignaciocano.com/tags/memory-management/index.xml" rel="self" type="application/rss+xml"/><item><title>The Rule of The Big Three (and a half) – Resource Management in C++</title><link>http://karpoke.ignaciocano.com/2015/01/18/the-rule-of-the-big-three-and-a-half-resource-management-in-c/</link><pubDate>Sun, 18 Jan 2015 10:59:00 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2015/01/18/the-rule-of-the-big-three-and-a-half-resource-management-in-c/</guid><description>&lt;blockquote&gt;
&lt;p&gt;The dynamic creation and destruction of objects was always one of the
bugbears of C. It required the programmer to (manually) control the
allocation of memory for the object, handle the object’s
initialisation then ensure that the object was safely cleaned-up after
use and its memory returned to the heap. Because many C programmers
weren’t educated in the potential problems (or were just plain lazy or
delinquent in their programming) C got a reputation in some quarters
for being an unsafe, memory-leaking language.&lt;/p&gt;
&lt;/blockquote&gt;</description></item></channel></rss>