Hi Chris,
I'm not seeing a particularly easy way to deep-copy the rest of the stuff
> in osg::DefaultUserDataContainer, either. The description list is a vector
> of strings, which are deep-copied, so that's fine, but the object list is
> harder as I'd need to cast the const off the CopyOp
Hi,
It's been pointed out to me that the DefaultUserDataContainer object list can
be a little bit more deeply copied with this change:
Code:
--- a/src/osg/UserDataContainer.cpp
+++ b/src/osg/UserDataContainer.cpp
@@ -56,7 +56,10 @@ DefaultUserDataContainer::DefaultUserDataContainer(const
Hi,
I'm not seeing a particularly easy way to deep-copy the rest of the stuff in
osg::DefaultUserDataContainer, either. The description list is a vector of
strings, which are deep-copied, so that's fine, but the object list is harder
as I'd need to cast the const off the CopyOp if I were to
Hi,
Is there a way to copy something if all I have is a ref_ptr to Referenced? I
see that Object has a clone method, but Referenced doesn't. This poses a
potential problem with deep-copying user data, as
osg::DefaultUserDataContainer::_userData is a ref_ptr.
Cheers,
Chris
--
Hi Chris,
On Mon, 23 Sep 2019 at 17:33, Chris Djali wrote:
> Good, but would the new enum entry be for the current behaviour or the new
> behaviour? If the current behaviour is a bug, then it makes sense to only
> keep the old behaviour as the new enum value so everyone gets the fix, but
>
Hi,
Good, but would the new enum entry be for the current behaviour or the new
behaviour? If the current behaviour is a bug, then it makes sense to only keep
the old behaviour as the new enum value so everyone gets the fix, but
conceivably there could be applications that rely on the current
Hi Chris,
On Sun, 22 Sep 2019 at 18:54, Chris Djali wrote:
> How do you want backwards compatibility to be handled? The current
> behaviour could just be dropped, or it could be available under a new flag
> name like SHALLOW_COPY_USERDATA (potentially with the same value as the
> current deep
Hi,
How do you want backwards compatibility to be handled? The current behaviour
could just be dropped, or it could be available under a new flag name like
SHALLOW_COPY_USERDATA (potentially with the same value as the current deep copy
one), or the new behaviour could be under a new flag name
Hi Chris,
My guess is that the deep copy support wasn't built in when I wrote it.
Different parts of the OSG developed at different points so sometimes you
get little inconsistencies. Feel free to modify the code to do a deep copy
when requested and generate a PR for it.
Robert.
On Fri, 20
9 matches
Mail list logo