Comments on general classes

Name of container

One thing missing in containers is the ability to get in one call the name in the TES of the container. The method 'name()' just returns the leave name, not the full name to be used e.g. for Linker access later. I think DataObject should have a method giving its full TES name, hiding the call to the registry interface of the object, a bit dirty.

-- OlivierCallot - 16 Sep 2005

Just one political remark: The DataObject is not private to LHCb and such a method was removed a few years ago after some lengthy discussions with ATLAS. I guess this argument does not hold for KeyedContainer - and that's anyhow the objects where the linkers work on.

-- MarkusFrank - 16 Sep 2005

New type of container ?

One of the probelm with our implementation of containers is the need of 'new' and 'delete' for all small objects. We discussed with Markus a more global change, which is based on the following idea: KeyedObjects are a bit heavy (thus slow) and difficult to manipulate, and a bit too generic. In our normal usage of KeyedContainers, we fill the container in one algorithm, and then only read it. But the container is in fact basically a vector of pointers to individual objects, whose creation (new, delete) is quite slow. It seems to be possible to have a new sort of containers, where the OBJECT is contained, not its pointer. This means the container will be a std::vector, not std::vector<plunk*>. The problem is clearly that pointer to such contained objects are not guaranteed to stay valid, if the vector is modified. The constraint we have to impose is that the container can not be modified once it has been 'read', i.e. once a pointer to one of the objects has been returned. This imposes a 'state' to the container, which is created read-write but becomes read-only after the first read access, i.e. any function other than 'insert'.

This could give a behaviour acceptable by ROOT browsing, will make filling of large collection of small objects (clusters) more efficient and so on. We could keep the access by key, useful but not the most frequent use, but by simplicity we could impose the key to be an 'int' and only that, that the objects are sorted by this key, and that a binary search is the only implemented method for fast access, the existing 'object' method of the Keyed container.

-- OlivierCallot - 16 Sep 2005