[Insight-users] Using smart pointer in a dll
Jim Miller
millerjv at gmail.com
Mon Apr 17 23:18:44 EDT 2006
You should never have to call Register/UnRegister. The SmartPointers will
take of that for you.
Here is the rule of thumb with respect to passing images into and out of
routines:
"Methods/functions should take raw pointers are arguments and return raw
pointers as return
values."
This rule of thumb avoid unnecessary manipulations of the reference count in
the object
and avoids the overhead of the mutex that surrounds the reference count.
THERE IS AN EXCEPTION TO THIS RULE:
"If a method/function returns an image that it created AND no other
reference to the
image is cached (for instance in an instance variable), then that image must
returned
as a SmartPointer."
This means the return type of a function should be a SmartPointer iff the
function
created the image and did not store it in another persistent SmartPointer.
If the return type is not a SmartPointer in this case, the image is actually
deallocated
when you exit the routine.
So instead of return void*, try returning a IT_PTu16_3D::Pointer
Jim
On 4/17/06, Thomas Lambertz <thomas at hexerei-software.de> wrote:
>
> Hi there,
>
> i have some newbie questions about the correct use of smart pointer in a
> dll. Afaik itk uses smart pointer which have a livetime of the scope
> where the are created in. So "all" i have to do is using itkImage (for
> example) within a common scope. Hm
>
> Can i instantiate a itkImage in an class constructor ? (i would say no -
> after return the image would be deleted - correct ?)
> I first tried this way but i get randomly violations when accessing the
> itkimage. So i searched the mailinglistarchive and found this
>
> http://public.kitware.com/pipermail/insight-users/2004-November/011095.html
> mail from Luis Ibanez. He told that there would be two options for
> approaching the problem. Option A was to create the image in a function
> and pass the smart pointer to the processing functions. He recommend
> this way. As a result the processing functions have to be called within
> this creating function (correct ?). But what about user interaction ?
> For example read a slice series into a itkimage and then let the user
> scroll through the slices. I would prefer to have to functions/methods
> to do this ReadSeriesIntoImage() and ShowSlice(). So when
> ReadSeriesIntoImage was done i have to leave my dll and wait for some
> user action - and if a have understand this correct i have no common
> scope between these two methods.
> Option B was a kind of faking a bit with Register() then return and
> then UnRegister(). I tried that way and i got violations by accessing
> that image randomly (which makes me believe, that the memorystructure
> was overwritten by something else). Maybe someone has enough patience to
> read my code...
>
> Read the fileSeries: (seems to work properly - its a modified copy and
> paste of what Luis wrote)
> void * dDicom::myFunction( std::string* seriesID)
> {
> FileNamesContainer fileNames;
> nameGenerator->GetSeriesUIDs();
> fileNames = nameGenerator->GetFileNames( seriesID->c_str() );
>
> ReaderType_u16_3d::Pointer reader = ReaderType_u16_3d::New();
> reader->SetImageIO( dio );
> reader->SetFileNames( fileNames );
> try {
> reader->Update();
> }
> catch (itk::ExceptionObject &ex) {
> MessageBox(GetActiveWindow(), ex.GetDescription() ,
> "ReadSeries", MB_SETFOREGROUND);
> }
>
> IT_PTu16_3D::Pointer fakeimage = reader->GetOutput();
> fakeimage->Register();
> return fakeimage.GetPointer();
> }
>
>
> a little wrapper
> int dDicom::getFile(std::string* seriesID) {
> storedImage=(IT_PTu16_3D *)this->myFunction(seriesID);
> storedImage->UnRegister();
>
> IT_PTu16_3D::RegionType inputRegion;
> inputRegion = storedImage->GetLargestPossibleRegion();
> IT_PTu16_3D::SizeType size = inputRegion.GetSize();
> slices = size[2];
> return 1;
> }
>
>
> Showing a Slice:
>
> void dDicom::showSlice(int slice) {
> try {
> IT_PTu16_3D::SizeType size;
> IT_PTu16_3D::RegionType inputRegion;
>
>
> //!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> // next line is where the crashes sometimes(!) happens
> // structure of storedImage overwritten ?
> // best way to provoke this on my maschine is to minimize/restore the
> window and then call showSlice - but its not deterministic
> // to prevent other sideeffects i excluded Paint and Resize Events from
> my Application
> inputRegion = storedImage->GetLargestPossibleRegion();
>
> size = inputRegion.GetSize();
> int max = size[2];
> size[2]=0; // only 2 dimensions
>
> IT_PTu16_3D::IndexType start = inputRegion.GetIndex();
> start[2]=slice;
>
> IT_PTu16_3D::RegionType desiredRegion;
> desiredRegion.SetSize( size );
> desiredRegion.SetIndex ( start );
>
> filter->SetExtractionRegion( desiredRegion );
> filter->SetInput( storedImage );
> filter->UpdateLargestPossibleRegion();
>
> connector->SetInput( filter->GetOutput() );
> connector->UpdateLargestPossibleRegion();
>
> myvtkviewer->SetInput( connector->GetOutput() );
> myvtkviewer->SetSize(size[0],size[1]);
> myvtkviewer->Render();
> }
> catch (itk::ExceptionObject &ex) {
> MessageBox(GetActiveWindow(), ex.GetDescription() , "ShowSlice",
> MB_SETFOREGROUND);
> }
> }
>
>
> Crashed could be localised in showSlice - i made some remarks before
> that line. storedImage is a member variable of my class dDicom and
> should store the image after reading. Much code for a mail and i hope i
> didnt bother you with that.
>
> Ok - what can i do at this point ? Reading the sliceSeries everytime (
> or even the requested slice) seems not very promising - espacially when
> refresh comes into play. One thought was to start a separate thread for
> holding the image - but that sounds like breaking a butterfly on a wheel
> to me.
>
> Maybe someone would be kind enough to give me some hints for a solution.
>
> Thanks in advance,
> with kind regards,
> Tom
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20060417/394f2c5e/attachment-0001.html
More information about the Insight-users
mailing list