Don’t store references to boost::shared_ptr

Note: This entry has been restored from old archives.

I should have known better, in fact I’m pretty sure I did know better, but it is so easy to fall into the trap of using reference members as often as possible. Actually, in other code I’ve not done this, so I’ll call it a “typo”, yeah. 🙂

No time to go into details with examples and all that, best to keep things simple anyway.

Avoid storing auto/smart/shared pointer references in the name of avoiding premature optimisation. You always have to think: will this be destroyed before this is destroyed. If it takes more than 10 seconds to work that out then steer clear of the reference path! Hoping it’ll all be OK is asking for trouble. Especially if you don’t own the calling code!

A shared pointer instance stores little state, so just copy the damn thing. This way the target instance will be destroyed when nothing needs it anymore, which is the whole point. Better a few copies than having things vanish earlier than you expected because you tried to game the system.

My new personal rule is: always copy shared/auto/smart pointers.

If the copy is a problem it’ll show up in profiling later and that’s when you work out how to fix it.

(Alas there isn’t an easy way around avoiding circular references.)

3 thoughts on “Don’t store references to boost::shared_ptr”

  1. what could possibly go wrong

    Using a reference counting smart pointer and then storing a reference/pointer to it that doesn’t increment the count.

    That ends well I’m sure 🙂

    The easy way around circular references is to use LISP instead… Which I’m sure helps in your particular domain.

  2. Lisp

    (It ends with a bang!)

    Funny you should mention ‘lisp’, I started learning it a couple of weeks ago. Inspired mostly by Paul Graham’s ‘arc’, though I decided to play with ‘lisp’ rather than ‘arc’. I’m just up to typical fibonacci-style toying so far, I’ve only managed to give a couple of hours a week to looking at it.

    Retrospectively, one of the most regrettable things about studying CS at USyd was the lack of exposure to non-mainstream programming. There was that one third year subject I did (DPL) where we learnt Prolog and Haskel (but the latter only for the advanced class.) DPL was non-compulsory though, so the vast majority of CS graduates would have come out having only been exposed to Java, C++, and C – plus, possibly, some Python, shell, and “Blue.”

  3. s/CS/IT/g

    Yeah, no lisp is a bizarre thing for a CS dept, though for an IT school I guess it’s expected.

    I did lisp in my hons/post stuff, not officially or with any help – but when you are working on “intelligent tutoring systems” the canonical one is implemented in and teaches lisp…

    I find doing http://projecteuler.net/ good for playing with new languages.

Comments are closed.