Currently ekiga doesn't do any automatic memory management : all is manual. That means that when several pieces of code want to share a same object, one must consider itself as owner and free it hoping nothing else still has it. It works because our objects have "removed" signals which makes all sharers forget about it immediately. The problem is that if two "owners" want to share an object, we need to use a SomethingProxy class, so they both can free it. This is cumbersome, and has a size cost -- both for the size of source code (a proxy is long and cumbersome to write) and for the executable code (another class). There is also the problem of what happens when an object emits a form, dies, and the form is submitted : I don't think it can happen as long as we only have gtk+ for the interface, as the form blocks ; but if the DBUS code gets revived, this could bite!

A possible solution is to turn to so-called 'smart' pointers. Unfortunately, they have a quite high size cost (templating mostly means each time we use them on another type, the code is re-implemented by the compiler for us). There is also the problem that although are so many of them, not that many are in the standard namespace. Other problem: how does one make a shared pointer on 'this', which would be needed for the forms issue? Sounds like a need for an intrusive pointer... Do we want to introduce a boost dependancy?

Another solution is to refcount our objects : either we embed the refcount directly in them, and they all grow (and we can have little issues with multiple inheritance), or we store them outside. In either case, both sharing and sending out forms is ok.

I wrote some sample test code to see how things fare. Here are three tests which do the same thing (and make valgrind happy) : they make twenty objects of different types, share them, then free them. One does things manually, one with external refcounts and one with std::tr1::shared_ptr.

Perhaps a mixed solution with external refcounting and a simple home-made smart pointer [very much like boost's intrusive_ptr -- but without the unneeded thread-safe overhead] would be best?