title: Adapter design pattern and memory management in C++
body: <p>Consider the following situation: I have a C++ module which takes an XML node as input, converts it to some other data structure, and returns the result.</p>
  
  <p>Right now this module is implemented using <a href="http://www.grinninglizard.com/tinyxmldocs/index.html" rel="nofollow">TinyXML</a>, so it takes TinyXML classes as input (specifically, a TiXmlNode). This is an issue, because it forces anyone wanting to use my module to use TinyXML for representing the entire document tree. For example, if a <a href="http://rapidxml.sourceforge.net/manual.html" rel="nofollow">RapidXML</a> user wants to use my module, he won't be able to, because the module expects a TinyXML node (and subsequent children), not a RapidXML one. Obviously, this is bad design because of poor reusability.</p>
  
  <p>To solve this problem, I'm willing to apply the <a href="http://en.wikipedia.org/wiki/Dependency_inversion_principle" rel="nofollow">Dependency inversion principle</a>. So I design this extremely simplified, DOM-like interface:</p>
  
  <pre><code>class Node
  {
      public:
          enum Type { TYPE_ELEMENT, TYPE_TEXT };
  
          virtual ~Node() { }
          virtual Type getType() = 0;
          virtual Node* getParentNode() = 0;
          virtual Node* getPreviousSibling() = 0;
          virtual Node* getNextSibling() = 0;
  };
  
  class Element : public Node
  {
      public:
          virtual ~Element() { }
          virtual const char* getName() = 0;
          virtual Node* getFirstChild() = 0;
          virtual Node* getLastChild() = 0;
          virtual const char* getAttribute(const char* name) = 0;
  };
  
  class Text : public Node
  {
      public:
          virtual ~Text() { }
          virtual const char* getText() = 0;
  };
  </code></pre>
  
  <p>I then implement these interfaces using the <a href="http://en.wikipedia.org/wiki/Adapter_pattern" rel="nofollow">Adapter</a> design pattern, wrapping the equivalent TinyXML classes. Or at least I try:</p>
  
  <pre><code>class AdapterNode : public Node
  {
      private:
          const TiXmlNode&amp; node;
      public:
          AdapterNode(const TiXmlNode&amp; node) : node(node) { }
          virtual Node* getFirstChild() { Uh... oh, wait.
  </code></pre>
  
  <p>You can see that I'm heading into a memory management nightmare: I'm supposed to return a preexisting, already-allocated Node here. And indeed I have a preexisting, already-allocated TiXmlNode (accessible through <code>node-&gt;FirstChild()</code>), but this is a TiXmlNode, not a Node! Writing <code>return new AdapterNode(node-&gt;FirstChild())</code> would result in an obvious memory leak, as the newly-allocated AdapterNode would never get <code>delete</code>'d by anyone.</p>
  
  <p>A few solutions crossed my mind to solve this memory management problem, but most of them are somewhat ugly. I'm asking for advice here: what would be your preferred solution to this situation?</p>