Pointers to Information Elsewhere in the Tree

Often we must record the fact that one piece of information is related to another piece. For example, we may want to associate a wire track with a strip track, and with scintillator hits that are located along the track. One way to do this in FARFALLA is to include pointers to nodes as data members of other nodes. For example, we may declare

class trackAssociationsNode : public F_Node {
  ...
  wireTrackNode *wire;
  stripTrackNode *strip;
  erpNode *erp1, *erp2;
  ...
}

Such a node might be added to an existing tree, as follows:

  ...
  for (int iWire = 0; iWire < ev->numChildren(wireTrackType); iWire++)
  {
    wireTrackNode *wirePtr;
    F_getChild(ev,wirePtr,iWire);
    for (int iStrip = 0; iStrip < ev->numChildren(stripTrackType); iStrip++)
    {
      stripTrackNode *stripPtr;
      F_getChild(ev,stripPtr,iStrip);
      ... // the variable tracks_match is set here
      if (tracks_match)
      {
        trackAssociationsNode *aPtr;
        F_addChild(ev,aPtr);
        aPtr->wire = wirePtr;
        aPtr->strip = stripPtr;
        ...
       }
     }
  }

Now the trackAssociationsNode in memory contains the actual memory addresses of the two other nodes. If the event tree is written to disk by a call to ev->outputSubtree() and later read back in, the two nodes it points at will be in new locations. FARFALLA can recreate the trackAssociationsNode in memory with correctly adjusted pointers. To get this behavior, you must observe the following rules:

• The pointed-at nodes must live in the same tree as the node containing pointers; more specifically, they must live in the same subtree which is being written to disk by a call to outputSubtree().
• In the class definition of the node containing pointers, the IOData() member function must input and output the pointers with a call to F_IOPtr() rather than F_IORec().

So the IOData() member function of trackAssociationsNode would look like this:

  virtual inline void IOData(iostream &file, F_inout choice,
                             F_length &nodeLength)
  {
    ...
    F_IOPtr(file,wire,choice,nodeLength);
    F_IOPtr(file,strip,choice,nodeLength);
    F_IOPtr(file,erp1,choice,nodeLength);
    F_IOPtr(file,erp2,choice,nodeLength);
    ...
  }

If you must create nodes containing pointers to nodes on other trees, you must either give up the ability to recreate the pointers when doing disk I/O, or handle yourself the pointer resolution by writing a blindingly clever IOData() routine. (In fact, if your node contains a pointer to anything other than a FARFALLA node on the same tree, the pointed-at data will not be correctly read to and from disk unless you handle it yourself in the IOData() routine. In fact this is not as difficult as it sounds; see the comments about wireTrackNode in Section for an example.)

Using pointers to nodes is the correct way in C++ to associate pieces of information at different places in the tree. In particular, let us try to dissuade you from two tempting alternatives.

First, rather than using a pointer, you may be tempted to store just the child number of the pointed-at node. For example, you may record the fact that the desired wireTrackNode is the 4th child of ev of type wireTrackType. However, suppose that sometime later the tree is pruned of all tracks less than 2 meters long. Later ev may not have a 4th child, or worse still, the 4th child may be a wireTrackNode that is not the desired one.

Second, you may be tempted to define a conglomeration node that contains all the information that would have been contained in all the pointed-at nodes. This might sometimes be acceptable but it has several distasteful consequences. First, if you write the event to disk you will be wastefully duplicating information. Furthermore, any software you or your collaborators have written to operate on wireTrackNodes would not be usable on the wire track information in your new node, and you create a maintenance headache for yourself if any enhancements are made to the standard wireTrackNode in the future.

What if you have a node pointing to another node, and the pointed-at node is deleted from memory before the tree is output? In that case FARFALLA will make the node pointers NULL the next time the tree is input. This may be quite normal; for example one could imagine the following analysis pathway:

• Initially a tree is created containing raw data and written to disk.
• Later some reconstructed data is calculated, and placed on the tree along with pointers to the raw data, and this expanded tree is saved to disk.
• Still later the raw data may be deemed unnecessary and deleted; the final tree will contain only reconstructed data, and NULL pointers to the now non-existent raw data.