** Changed in: kaliveda/1.8
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of KaliVeda
Development Team, which is subscribed to KaliVeda.
https://bugs.launchpad.net/bugs/504779
Title:
bit conflict in KVSeqCollection/KVList: kIsOwner and kSignals both
address BIT(14)
Status in KaliVeda data analysis framework:
Fix Released
Status in KaliVeda 1.7 series:
Fix Released
Status in KaliVeda 1.8 series:
Fix Released
Bug description:
in versions <= 1.7.4b: KVList::kSignals bit flag for sending Modified()
signals is the same as TCollection::kIsOwner bit flag (BIT(14))
in trunk: KVSeqCollection::kSignals bit flag for sending Modified() signals
is the same as TCollection::kIsOwner bit flag (BIT(14))
resulting conflict means that for <=1.7.4b, creating a KVList using the
default constructor KVList(Bool_t owner=kTRUE)
is not sufficient to ensure that list owns its objects, as in this
constructor we do:
SetOwner(owner);
ResetBit(kSignals);// <=== same as SetOwner(kFALSE) !!!
if one subsequently calls SendModifiedSignals() or SetOwner() then BOTH
signals and ownership are activated
(with potentially catastrophic results)
in trunk version, ResetBit(kSignals) is called in KVSeqCollection ctor before
SetOwner(owner) is called in KVList ctor,
so KVList DOES own its objects... and sends signals as well. The same
conflict between SendModifiedSignals() and SetOwner()
exists.
_______________________________________________
Mailing list: https://launchpad.net/~kaliveda-dev
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kaliveda-dev
More help : https://help.launchpad.net/ListHelp
