StoreGate: allow parent container for DecorHandleKey
When reading/writing decorations from/on a container one requires a VarHandleKey for the container and a DecorHandleKey for the decoration, which usually leads to duplication of the container name:
SG::WriteHandleKey<MyCont> m_key{this, "Key", "MyCont"};
SG::WriteDecorHandleKey<MyCont> m_decorKey{this, "DecorKey", "MyCont.MyDecor"};
This can now be avoided by passing the "parent container" in the constructor:
SG::WriteDecorHandleKey<MyCont> m_decorKey{this, "DecorKey", m_key, "MyDecor"};
Also add testing tool and unit test to AthExStoreGateExample+ControlTest.
Implementation details:
- The
DecorHandleKey
classes get an extra (property) constructor that takes aVarHandleKey
. - The
DecorHandleKey
now holds an additional pointer to the associated parent container (nullptr
by default). This is really the same as the already existingm_contHandleKey
. So we could have just kept it in a (non-)owning pointer depending on the use-case. But that would require a dedicated copy constructor for this class, etc. - In case a parent container is used in the key declaration, the
pythonRepr
becomes the decoration name only. Specifying the parent container in addition will result in an exception.
Edited by Frank Winklmeier