Hi Robert and Christian,
Thank you for your answers. Now I understand why my expectations on
using the shallow copy were not working.
So I will just share the same osg::Image.
Also thanks for pointing out the allocation mode, it can be very useful
if I want to manually manage the _data
Hi Pierre-Jean,
The osg::Image constructor doesn't support shallow copy for the
internal image data, it will allocated a new image block and copy
across the data. This means for the image data itself it's effective
a deep copy.
A shallow copy would be technically possible by would force one to
looking at the osg::Image header file, it appears that the data storage is
not protected through reference counting.
AllocationMode _allocationMode;
unsigned char* _data;
the default allocation mode for an osg::Image is USE_NEW_DELETE, hence when
one instance of your shallow copy
Hi Sebastian,
What do you mean by "reachable"? Deallocation doesn't mean the memory
is cleaned or something. So having a raw pointer to the deallocated
memory might give you the same data as long as no one is allocating
memory there.
I mean that after the first image is deleted, I still can
Hi Pierre
Hi,
In my application I have two osg::Images, the second one is a shallow copy of
the first one thanks to the copy constructor.
Is it safe to delete the first image and keep only the second one, or should I
use deep copy instead?
My tests showed me that the data is still reachable
Hi,
In my application I have two osg::Images, the second one is a shallow copy of
the first one thanks to the copy constructor.
Is it safe to delete the first image and keep only the second one, or should I
use deep copy instead?
My tests showed me that the data is still reachable but when
6 matches
Mail list logo
