[IGSTK-Users] igstkImageSpatialObject memory management problem

[Torleif Sandnes]

Hi Louis.
Thanks for your reply!

Not using the singleton pattern and instantiating a volumemanager  
with VolumeManager::New(), the problem goes away.
I have put together a mininal application that reproduces the problem  
with singleton pattern/DICOM image loading and attached it with this  
email.
In the attached example, the VolumeManager is not in a library, but  
the problem is still present.

Please set the constant  TestVolumeManager::DICOMSERIES_PATH to a  
suitable DICOM MR image.

> 1) Why are you using a Singleton for the volume Manager ?

There should never be more than one volume manager in my application.

> 2) Are you creating a shared library with this class ?

No, the class is in a static library. Also, linking the volumemanager  
directly with the executable, the problem is still present.
(As in the attached example)

>
> 3) Can you please send the actual source files and
>    test files ? something we could compile and run
>    in order to reproduce the problem.
>
>    In the code snippets that you sent we can't find
>    the declaration of "imageSpatialObject_"... for
>    example

See the attached files.

> BTW:  Please don't do:
>
>         using std::vector;
>         using std::string;
>
>
> This is equivalent to opening the namespace for these
> symbols. Instead of doing this, you should always use
> the std:: namespace specifier.

Well, I agree that the "using" directive shouldn't be used in header  
files and thus pollute every file that includes that header file.
I can also agree that putting "using" directives on the top of  
implementation, (cpp/cxx), files can be bad, but IMHO it is okay in  
more limited scopes to avoid writing the namespace prefix over and  
over again.

Regards,
Torleif Sandnes
Sintef Health Resarch
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CMakeLists.txt
URL: <http://public.kitware.com/pipermail/igstk-users/attachments/20070620/18a265f5/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.cpp
Type: application/octet-stream
Size: 155 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/igstk-users/attachments/20070620/18a265f5/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testvolumemanager.cpp
Type: application/octet-stream
Size: 902 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/igstk-users/attachments/20070620/18a265f5/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testvolumemanager.h
Type: application/octet-stream
Size: 632 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/igstk-users/attachments/20070620/18a265f5/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: volumemanager.cpp
Type: application/octet-stream
Size: 3413 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/igstk-users/attachments/20070620/18a265f5/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: volumemanager.h
Type: application/octet-stream
Size: 2137 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/igstk-users/attachments/20070620/18a265f5/attachment-0004.obj>