[Insight-users] itk::SmartPointer - problem making code const-correct

[Stuart Golodetz]

  Hi Luis,

Thanks for the helpful response.

Luis Ibanez wrote:
> Hi Stuart,
>
>
> Thanks for your detailed question.
>
>
> 1) When writing functions that take an image as an argument,
>     we usually use a Raw pointer instead of a Smart Pointer.
>
>     The reason is that SmartPointers will not do polymorphism.
>
>     That is, if you use smart pointers, you can call that function
>     later with an argument that is a derived class of that image
>     type.
Not sure I follow what you mean here - if SmartPointers don't support 
polymorphism, then doesn't that mean that this sort of thing won't work?

struct B { virtual ~B() {} };
struct D : B {};
void f(itk::SmartPointer<B> b) {}
...
itk::SmartPointer<D> d;
f(d);

Whereas this always works by the rules of the language:

void f(B *b) {}
D *d;
f(d);

I think I would understand what you mean if your last paragraph said 
"That is, if you use *raw* pointers..." [emphasis mine]. Or am I getting 
the wrong end of the stick? :)
>     If you look at most ITK filters, you will find that raw pointers
>     are used in the API, for passing and receiving images.
>
>     However, when we call those functions we pass a SmartPointer
>     to them (since SmartPointers know how to cast themselves as
>     raw pointers).
>
>
> 2) The only case in which you may want to pass an image
>     SmartPointer as argument to a function is when you are
>     creating that image inside the function.
>
>     In that case, passing the SmartPointer by reference is
>     a reasonable choice.
I think I've been trying to use itk::SmartPointer as a 
boost::shared_ptr, which may not be the best plan :) The idea being that 
the pointed-to image or whatever won't get destroyed as long as I'm 
holding an itk::SmartPointer to it, so I can construct it somewhere, 
pass the itk::SmartPointer into a function, store a copy of the 
itk::SmartPointer somewhere else and not worry if the original 
itk::SmartPointer to the image no longer exists.

What I've been missing is that itk::SmartPointer appears to use 
*intrusive* reference-counting (i.e. the reference count is stored in 
the image itself), so that if I pass in a raw image pointer to a 
function I can then construct a separate itk::SmartPointer the other end 
from it that will share the reference count with the original 
itk::SmartPointer. Is that right?
> 3) Please note that the construction
>
>           const    Image::ConstPointer &  ptr ....;
>
>     prevents the internal mechanisms of the SmartPointer
>     from working, since the "const" keyword prevents the "ptr"
>     variable from changing. (strictly speaking it prevents the
>     smart pointer from calling the non-const method Register()
>     on the object that it points to).
Offhand, I think that could be easily changed by making Register() and 
UnRegister() const methods, since that would only have the effect of 
making m_Pointer itself const, not the ObjectType it points to:

/** The pointer to the object referrred to by this smart pointer. */
ObjectType* m_Pointer;

void Register() --> const <--
{
    if(m_Pointer) { m_Pointer->Register(); }
}
 
void UnRegister() --> const <--
{
    if(m_Pointer) { m_Pointer->UnRegister(); }
}

I haven't really looked at the implications that would have elsewhere 
though - any thoughts?

Cheers,
Stu
>   Regards,
>
>
>         Luis
>
>
> -------------------------------------------------------------------------
> On Thu, May 27, 2010 at 1:21 PM, Stuart Golodetz <itk at gxstudios.net 
> <mailto:itk at gxstudios.net>> wrote:
>
>     Hi,
>
>     Hope this is the right place to post this. I was just wondering if 
>     there's a reason why itk::SmartPointer was designed so as not to allow e.g.
>
>     itk::Image<int,3>::Pointer image;
>     const itk::Image<int,3>::ConstPointer& cimage = image;
>
>     ?
>
>     The equivalent with boost::shared_ptr is allowed, e.g.
>
>     boost::shared_ptr<int> p(new int);
>     const boost::shared_ptr<const int>& cp = p;
>
>     This doesn't seem like a major problem, until you start writing 
>     functions taking const itk::Image<...>::ConstPointer& parameters - at 
>     which point it won't let you pass a normal Pointer in without explicitly 
>     constructing a ConstPointer from it. Now the types are often quite long, 
>     and it's annoying to have to add extra typedefs in the calling code just 
>     for that purpose. Duplicating the functions with const 
>     itk::Image<...>::Pointer& parameters doesn't work either, because you 
>     get a combinatorial explosion when you have multiple such parameters. 
>     For instance, with 3 parameters, you have to create functions with 
>     combinations:
>
>     const Pointer&, const Pointer&, const Pointer&
>     const Pointer&, const Pointer&, const constPointer&
>     const Pointer&, const ConstPointer& const Pointer&
>     // more here
>     const ConstPointer&, const ConstPointer& const ConstPointer&
>
>     This seems like an unproductive way to spend one's time, to say the 
>     least. The only other "reasonable" alternative I've managed to come up 
>     with that doesn't either (a) clutter up the call site or (b) cause the 
>     combinatorial explosion just outlined, is to just use the non-const 
>     Pointers everywhere and abandon the idea of making the code 
>     const-correct. But that seems defeatist to me  :)  Please could you tell 
>     me if there's something I'm missing? (And if so, what?)
>
>     Cheers,
>     Stuart
>         
>
>
>     _____________________________________
>     Powered by www.kitware.com <http://www.kitware.com>
>
>     Visit other Kitware open-source projects at
>     http://www.kitware.com/opensource/opensource.html
>
>     Kitware offers ITK Training Courses, for more information visit:
>     http://www.kitware.com/products/protraining.html
>
>     Please keep messages on-topic and check the ITK FAQ at:
>     http://www.itk.org/Wiki/ITK_FAQ
>
>     Follow this link to subscribe/unsubscribe:
>     http://www.itk.org/mailman/listinfo/insight-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100528/fb937202/attachment.htm>