title: Using reference as class members for dependencies
body: <p>I am going back to C++ after spending some time in memory-managed languages, and I'm suddently kinda lost as to what is the best way to implement dependency injection. (I am completely sold to DI because I found it to be the simplest way to make test-driven design very easy).</p>
  
  <p>Now, browsing SO and google got me quite a number of opinions on the matter, and I'm a bit confused. </p>
  
  <p>As an answer to this question, <a href="https://stackoverflow.com/questions/352885/dependency-injection-in-c">Dependency injection in C++</a> , someone suggested that you should not pass raw pointers around, even for dependency injection. I understand it is related to ownership of the objects. </p>
  
  <p>Now, ownership of objects is also tackled (although not into enough details to my state ;) ) in the infamous google style guide : <a href="http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Smart_Pointers" rel="noreferrer">http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Smart_Pointers</a></p>
  
  <p>So what I understand is that in order to make it clearer which object has ownership of which other objects, you should avoid passing raw pointers around. In particular, it seems to be against this kind of coding : </p>
  
  <pre><code>class Addict {
     // Something I depend on (hence, the Addict name. sorry.)
     Dependency * dependency_;
  public:
     Addict(Dependency * dependency) : dependency_(dependency) {
     }
     ~Addict() {
       // Do NOT release dependency_, since it was injected and you don't own it !
     }
     void some_method() {
       dependency_-&gt;do_something();
     }
     // ... whatever ... 
  };    
  </code></pre>
  
  <p>If Dependency is a pure virtual class (aka poor-man's-Interface ), then this code makes it easy to inject a mock version of the Dependency (using something like google mock). </p>
  
  <p>The problem is, I don't really see the troubles I can get in with this kind of code, and why I should want to use anything else than raw pointers ! Is it that it is not clear where the dependency comes from?</p>
  
  <p>Also, I read quite a few posts hinting that one should really be using references in this situation, so is this kind of code better?</p>
  
  <pre><code>class Addict {
     // Something I depend on (hence, the Addict name. sorry.)
     const Dependency &amp; dependency_;
    public:
     Addict(const Dependency &amp; dependency) : dependency_(dependency) {
     }
     ~Addict() {
       // Do NOT release dependency_, since it was injected and you don't own it !
     }
     void some_method() {
       dependency_.do_something();
     }
     // ... whatever ... 
  };
  </code></pre>
  
  <p>But then I get other, equally authoritive advices <em>against</em> using references as member: <a href="http://billharlan.com/pub/papers/Managing_Cpp_Objects.html" rel="noreferrer">http://billharlan.com/pub/papers/Managing_Cpp_Objects.html</a></p>
  
  <p>As you can see I am not exactly sure about the relative pros and cons of the various approaches, so I am a bit confused. I am sorry if this has been discussed to death, or if it is only a matter of personnal choice and consistency inside a given project ... but any idea is welcome.</p>
  
  <hr>
  
  <p><strong>Answers summary</strong></p>
  
  <p>(I don't know if it is good SO-tiquette to do this, but I'll add code example for what I gathered from answers...)</p>
  
  <p>From the various responses, here's what I'll probably end up doing in my case:</p>
  
  <ul>
  <li>pass dependencies as reference (at least to make sure NULL is not possible)</li>
  <li>in the general case where copying is not possible, explicitly disallow it, and store dependencies as reference</li>
  <li>in the rarer case where copying is possible, store dependencies as RAW pointers</li>
  <li>let the creator of the dependencies (factory of some kind) decide between stack allocation or dynamic allocation (and in the latter case, management through a smart pointer)</li>
  <li>establish a convention to separate dependencies from own resources</li>
  </ul>
  
  <p>So I would end up with something like:</p>
  
  <pre><code>class NonCopyableAddict {
      Dependency &amp; dep_dependency_;
  
      // Prevent copying
      NonCopyableAddict &amp; operator = (const NonCopyableAddict &amp; other) {}
      NonCopyableAddict(const NonCopyableAddict &amp; other) {}
  
  public:
      NonCopyableAddict(Dependency &amp; dependency) : dep_dependency_(dep_dependency) {
      }
      ~NonCopyableAddict() {
        // No risk to try and delete the reference to dep_dependency_ ;)
      }
      //...
      void do_some_stuff() {
        dep_dependency_.some_function();
      }
  };
  </code></pre>
  
  <p>And for a copyable class:</p>
  
  <pre><code>class CopyableAddict {
      Dependency * dep_dependency_;
  
  public: 
      // Prevent copying
      CopyableAddict &amp; operator = (const CopyableAddict &amp; other) {
         // Do whatever makes sense ... or let the default operator work ? 
      }
      CopyableAddict(const CopyableAddict &amp; other) {
         // Do whatever makes sense ...
      }
  
  
      CopyableAddict(Dependency &amp; dependency) : dep_dependency_(&amp;dep_dependency) {
      }
      ~CopyableAddict() {
        // You might be tempted to delete the pointer, but its name starts with dep_, 
        // so by convention you know it is not your job
      }
      //...
      void do_some_stuff() {
        dep_dependency_-&gt;some_function();
      }
  };
  </code></pre>
  
  <p>From what I understood, there is no way to express the intent of "I have a pointer to some stuff, but I don't own it" that the compiler can enforce. So I'll have to resort to naming convention here...</p>
  
  <hr>
  
  <p><strong>Kept for reference</strong></p>
  
  <p>As pointed out by Martin, the following example does not solve the problem.</p>
  
  <p>Or, assuming I have a copy constructor, something like:</p>
  
  <pre><code>class Addict {
     Dependency dependency_;
    public:
     Addict(const Dependency &amp; dependency) : dependency_(dependency) {
     }
     ~Addict() {
       // Do NOT release dependency_, since it was injected and you don't own it !
     }
     void some_method() {
       dependency_.do_something();
     }
     // ... whatever ... 
  };
  </code></pre>