Re: [Opensg-users] Method deepClone possibly not correct

[Carsten N. <car...@gm...>]

    Hello Johannes,

On Wed, Mar 10, 2021 at 2:43 PM Johannes Brunen <jb...@da...>
wrote:
> IMHO we are in the realm of modulo bug :-)
> Below, I have copied the two relevant functions with their comments.
>
> My scenario:
>
> MaterialGroup* mgrp = ...;
> vector<OSG::ReflexiveContainerType*> shareTypes;
> shareTypes.push_back(&MyMaterial::getClassType());
> cloned_mgrp = deepClone(mgrp, shareTypes, ...);
>
> Method deepClone calls dstField->shareValues(srcField) if
>
> TypePredicates::typeDerivedFrom(
>                         shareTypes.begin(),
>                         shareTypes.end  (), *rcType))
>
> results true. 'rcType' is the MaterialGroup's 'material' field:
>
> const ReflexiveContainerType *rcType =
>                 dynamic_cast<const ReflexiveContainerType *>(
>                     &pointerType->getContentType());
>
> Now, the predicate 'typeDerivedFrom' results in true if any of the
> sequence's elements is a base class of the third parameter 'type',
> i.e. rcType, i.e. "Material". That is the way 'typeDerivedFrom'
> is implemented.
>
> Hope I could clarify my point ;-)

ok, I think I understand what you are saying, but believe the issue is that
the declared type of the field is being used to determine if something
should be shared while for your use-case you want the dynamic type of the
pointed to object to be used. So the situation is a bit like having a
pointer to a base class (the static type of the field) that points to a
derived type object (dynamic type of object pointed to by the field) and
you want behavior to depend on the dynamic type, but currently it uses the
static one.
I don't think changing typeDerivedFrom to typeBaseOf would do the right
thing for you either, because that would mean any field with a type that is
a base of MyMaterial (which includes FieldContainer) would be shared; i.e.
everything would be shared. To be honest even if it did do the right thing
I'm not sure it would be safe to change the functions semantics in this way
- although I can definitely see the usefulness of your proposed behavior ;)

Cheers,
Carsten