Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>[update 1]</strong><br> If you can always guarantee the dependency outlives the addict, you <strong>can</strong> use a raw pointer/reference, of course. between these two, I'd make a very simple decision: pointer if NULL is allowed, reference otherwise. </p> <p>(The point of my original post was that neither pointer nor reference solve the lifetime problem)</p> <hr> <p>I'd follow the infamous google style guideline here, and use smart pointers.</p> <p>Both a pointer and a reference have the same problem: you need to make sure the dependency outlives the addict. That pushes a quite nasty responsibility onto the client.</p> <p>With a (reference-counted) smart pointer, the policy becomes <em>dependency is destroyed when noone uses it anymore</em>. Sounds perfect to me. </p> <p>Even better: with <code>boost::shared_ptr</code> (or a similar smart pointer that allows a type-neutral destruction policy) <em>the policy is attached to the object at construction</em> - which usually means everything affecting the dependency ends up in a single place.</p> <p>The typical problems of smart pointers - overhead and circular references - rarely come into play here. Dependency instances usually aren't tiny and numerous, and a dependency that has a strong reference back to its addicts is at least a code smell. (still, you need to keep these things in mind. Welcome back to C++)</p> <p>Warning: I am not "totally sold" to DI, but I'm totally sold on smart pointers ;)</p> <p><strong>[update 2]</strong><br> Note that you can always create a <code>shared_ptr</code> to a stack/global instance using a null deleter.<br> This requires both sides to support this, though: addict must make guarantees that it will not transfer a reference to the dependency to someone else who might live longer, and caller is back with the responsibility ensuring lifetime. I am not to happy with this solution, but have used this on occasion.</p>
    singulars
    1. This table or related slice is empty.
    1. POUsing reference as class members for dependencies
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USpeterchen
    1. USpeterchen
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTDownMod
    1. COThe advice "use shared pointers" only makes sense if you know how the pointer has been assigned - has the thing it points to been dynamically allocated? Quite possibly, the object being injected has been created automatically or statically, in which case using a shared pointer (or any smart pointer) would be a disaster.
      singulars
      1. PO
      1. This table or related slice is empty.
    2. COWell, I will typically have two situations : test code, where I will typically inject the address of an instance of a mock version of the class, that I would probably create on the stack for ease of writing. In the "production" code, I would inject the address of a dynamically allocated object. But only the object that does the allocation would own the object.
      singulars
      1. PO
      1. USphtrivier
    3. COSmart pointers bring their own complexity, but each to his own. Regarding being sold, you don't have to buy DI when all it represents is poor-man templates.
      singulars
      1. PO
      1. USrama-jka toti
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload