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

[Frederic Perez]

Hello Stuart,

I would like to be able to do those kinds of assignments too!

For example, in our group we have functions like this one:

     template<typename TITKImgType>
     bool
     WriteFile(
         const std::string& a_fullFilename,
         typename TITKImgType::ConstPointer);

declared this way to promise that WriteFile won't modify the input image.
(By the way, the template stuff is not relevant to this thread.)

In order to workaround the const-vs-nonconst problem, we do calls like this:

typedef itk::Image<int, 3> ImgType;
ImgType::Pointer image = ImgType::New();
...
WriteFile<ImgType>("out.mhd", image.GetPointer());

Unfortunately, this populates the code with lots of GetPointer() that we
would like to get rid of.
Not a real solution, but maybe you can use it.

I would like to hear more on this issue.

Cheers,

Frederic Perez

On Thu, May 27, 2010 at 7: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/36916698/attachment-0001.htm>