Re: [osg-users] DEEP_COPY_USERDATA isn't that deep

2019-12-13 Thread Robert Osfield
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

Re: [osg-users] DEEP_COPY_USERDATA isn't that deep

2019-10-20 Thread Chris Djali
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

Re: [osg-users] DEEP_COPY_USERDATA isn't that deep

2019-09-28 Thread Chris Djali
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

Re: [osg-users] DEEP_COPY_USERDATA isn't that deep

2019-09-28 Thread Chris Djali
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 --

Re: [osg-users] DEEP_COPY_USERDATA isn't that deep

2019-09-24 Thread Robert Osfield
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 >

Re: [osg-users] DEEP_COPY_USERDATA isn't that deep

2019-09-23 Thread Chris Djali
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

Re: [osg-users] DEEP_COPY_USERDATA isn't that deep

2019-09-23 Thread Robert Osfield
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

Re: [osg-users] DEEP_COPY_USERDATA isn't that deep

2019-09-22 Thread Chris Djali
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

Re: [osg-users] DEEP_COPY_USERDATA isn't that deep

2019-09-20 Thread Robert Osfield
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