[Insight-developers] Introducing itk::AutoPointer

[Bill Lorensen]

I think it is best not to do any extensive changes to the system until after the upcoming meeting.

Bill

At 07:51 PM 5/30/02 -0400, Luis Ibanez wrote:

>Hi,
>
>As you may recall, the Cell classes were recently
>modified to not derive from the itkLightObject.
>
>This change allowed to avoid the time overhead of
>Mutex calls during Register() and Unregister()
>operations.
>
>The change, however difficulted some of the operations
>required in the itkMesh and itkCells class.
>
>In particular:
>
>itkCells are capable of returning their boundaries,
>for example a triangle cell is capable of returning
>the three line cells which are its boundaries.
>
>The line cells are not actually stored but rather
>constructed on the fly upon demand. This creates a
>confusing memory managment situation, since it is
>not clear who will be responsible for memory release.
>
>At the level of the itkMesh that was solved by creating
>a list which contains pointers to cells whose memory
>should be released upon destruction of the Mesh.
>At the level of the Cell, however it is not possible
>to apply the same solution.
>
>Given that cells are not intended to be shared,
>this is not exactly a problem of reference counting.
>We just want to make sure that somebody will take care
>of releasing the memory allocated for the cell.
>
>In response to this need the new class itk::AutoPointer
>is being introduced.  The AutoPointer is a helper
>class that holds a raw pointer. In the same way that
>the itkSmartPointer the AutoPointer is designed to
>look pretty much like a raw pointer.
>
>The special feature of this new pointer type is that
>upon destruction it will release the memory allocated
>by its raw pointer.  That guarranties that at the
>end of the scope memory leaks will be controlled.
>The memory can also be released explicitly before.
>
>There is a std::auto_ptr already. The reason for not
>using this standard class is that it has templated
>method that will result in difficulties during
>wrapping.
>
>Methods returning Cells from the itkMesh and itkCell
>classes will return AutoPointers in order to transfer
>the responsibility of memory release to the recipient
>if the call.
>
>Storage of Cells inside the itkMesh will still be done
>by a VectorContainer of raw pointers to cells.
>
>
>The details of the implementation and the changes
>over the toolkit are being worked out.
>
>
>
>     Luis
>
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers@public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers