programming

smart pointers

this weekend i have been playing around with smart pointers in c++. this is at least my 5th try and i failed again, though this was my best effort so far.

the problem... they cause more problems than they solve.

two aspect i like for my code is that it is as simple as possible and is not fragile. smart pointers don't do well with either.

for my test i took the basic gamebasis class layout and ported it to c++ and smart pointers. the smart pointer implementation i used was the one from boost.org. it is considered my most peoples to be the best implementation. i used boost::shared_ptr.

in order to make things more clean and not have disgusting boost::shared_ptr templates all over the damn place, i made typedefs for all my types and put them in my main gb.hpp header.

typedef boost::shared_ptr gbGlyphPtr;
typedef boost::shared_ptr gbGlyphNodePtr;
typedef boost::shared_ptr gbGraphicsPtr;
typedef boost::shared_ptr gbObjectPtr;
typedef boost::shared_ptr gbOpenGLPtr;
typedef boost::shared_ptr gbPlatformPtr;
typedef boost::shared_ptr gbUniversePtr;
typedef boost::shared_ptr gbWindowPtr;

it baffles me to why more people don't do this. you'll see people often typedefing things, but only local. why not make them global? a smart pointer to a gbWindow is always going to be a smart pointer to gbWindow. you spent the time writing your class interface, you can't spend 2 seconds and write a typedef?

so i got my non-smart pointer implementation working first and then switched it to smart pointers. right away i came into a big problem.. using 'this' in constructors. oops. sorry dude, can't do that. boost has a solution for it, enable_shared_this or something like that, but as i understand it, it does not do much good for a hierarchy because you'll get a copy of their weak ptr in each and every sub-class. lame.

so i rolled my own with my own gbObject base class intended for all reference counted objects, which is most. what a bitch. the boost_shared_dynamic_cast didn't seem to work as advertised so i ended up doing some ugly casting oh well, it worked and maybe it will be fixed in a later version.

blah, blah, blah. so i ended up getting things working minus the gbOpenGL using smart pointers. it would start things up, allocate, and deallocate like magic on exit. all of my constructors were made protected and you could only get smart pointers to my objects via a static create method. very nice. doing a search for 'new' only had hits in those create methods.

so i implemented gbOpenGL and things broke. see, you have to worry about nasty circular references. since the gbOpenGL is a gbGraphics and a gbGraphics needs to keep around a gbWindow and the gbWindow needs to keep around a gbGraphics, you get some circular action. ok.. no worries, i'll switch the smart pointer in gbGraphics to a weak pointer and it should just work.

nope. wtf. this crap is supposed to be care free. bullshit.

maybe i should spend some more time working out the kinks, but i often program by gut instinct. this stuff feels fragile. i hate fragile.

my usual memory management strategy is to just not really bother with it until there is a problem. i make games, not flight control software. who cares if you leak a few hundred bytes over the course of a day. guess what, if you really wanted to track down those bytes, you can do it pretty easily.

the other option is to be very deligent about this stuff during development. the problem is it dramatically slows down development speed and things feel much more fragile. it is really easy to be over aggressive and delete things that don't need to be deleted. do that. crash. i prefer to just not crash and leak a few hundred bytes during development. if i find i am leaking all over the place, i fix the problem. kinda like optimization except your profiling tool is in your task manager.