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

[Luis Ibanez]

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.

    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.


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).



  Regards,


        Luis


-------------------------------------------------------------------------
On Thu, May 27, 2010 at 1:21 PM, Stuart Golodetz <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
>
> 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/b1873a25/attachment-0001.htm>