Points for Discussion about the BOS-C++ Interface

The BOS-C++ interface presented here is only a first trial. There are quite a few questions that should be discussed before a "production strength" implementation of something based on these ideas should be undertaken.

These are the points that come to my mind. Mail me (Benno List, blist@mail.desy.de) your opinions or further questionable issues!

Style Guide

• The for-scope problem
  Between older C++ definitions and the ANSI draft standard the rules for the scope of variables in for loops have changed. Consider this example:

        #include"iostream.h"
        int i=1;                      // global variable
        void main () {
          for (int i=0; i < 5; i++) { // local i hides global i in for-loop
            if (i == 3) break;
          }
          cout << i;                  // local or global i?
        } 

  This is perfectly valid code according to the old and the new standard, so no compiler could warn you about this. In the old standard the i defined in the for-loop header remains in scope, therefore the program should print "3" (I did not try it). According to the ANSI standard, the scope of the i defined in the loop header is only the loop body, and therefore the routine should print "1".
  This problem is bound to stay with us a long time, and should be avoided. Therefore generally definitions in the header of a for-loop should be forbidden.
• Use of exceptions
  Should exceptions be used (I think yes!). If so: How? Are derived exception classes allowed (I think they should. But compiler support is dim yet)?
  What should be done as long as compilers are with us which compile code that uses exceptions, but ignores them? Often, an exception is a way out of a situation that otherwise leads to a segmentation violation, most notably in the case where a function would be forced to return a 0 pointer. Therefore printing an error message after the (ignored) throw statement, possibly "enhanced" by calling H1STOP, may give the user at least a hint why his program crashed.
• Naming conventions
  Some sort of naming convention should be introduced. Look at the BaBar style guide for good recommendations.
• Namespaces?
  The ANSI standard defines name spaces. I think they are a good tool to make transparent where a routine comes from. In that case one would use e.g. h1rec::cjcrec() instead of just cjcrec, or h1util::jrdata(name, iret).
  If that is too clumsy, e.g. for h1util, all names in a namespace can be made global. This would be a good idea for h1util, or look, or bos, maybe not such a good idea for use of an odd h1rec routine.
  To make old C++ code backward compatible, the header files could include a directive to generally make all names available globally by using a preprocessor directive.

Wrapper files: C or C++?

Using the STL?

Exceptions

• Should they be used at all? (I think: yes)
• What to do until on all machines compilers which support exception handling exist?
• A suitable hierarchy of exceptions must be defined.

Locking mechanism/associated structures/parallel banks

• Should there be a special construct for treating parallel banks, e.g. for the calorimeter banks?
• Could one have a special locking class template which maintains a structure parallel to a bank which can be used to log or flag tracks? How should a user interface for such a structure look like? Should it be a special class, say "LockableTable", with predefined access functions like dtra[i].flag(1)? Or maybe one could have a sort of flag class, say

    class flags {
      public:
        int goodtrack;
        ind good_forward_track;
    }; 

  and associate it with the table:

    void f () {
      LockableTable dtra ("DTRA", 0);
      for (i = 1; i <= dtra.rows(); i++) {
        if (dtra[i].lock()->goodtrack) {
          // do something
        }
      }
    } 

  The "lock()" function would provide the pointer to the appropriate element of the "flags" class. But the syntax is somehow still not nice.

Syntax of StrBank

  struct qtrarow {
  // Conditions for good central track:
    float th_min_c;  // min. theta [degrees] 
    float th_max_c;  // max. theta [degrees] 
    float rs_max_c;  // max. start radius [cm] 
    float re_min_c;  // min. end radius [cm] 
    float rl_min_c;  // min. radial length [cm] 
    float pt_min_c;  // min. p_T [GeV] 
  // and much more... 
  }
  
  void f () {
    StrBank qtra ("QTRA", 0);
  
    float thet_min_cen = qtra.th_min_c;  // qtra acts like structure
  
    qtrarow cuts = *qtra;                // qtra acts like pointer
  
  } 

  void f () {
    StrBank qtra ("QTRA", 0);
  
    float thet_min_cen = qtra->th_min_c;  // qtra acts like pointer
    //                    ^^ not "." anymore!
  
    qtrarow cuts = *qtra; // stays
  } 

Should bank name and number be kept in the "Bank" object?

  void f () {
    StrBank qtra ("QTRA", 0); // try to open bank
  
    if (!qtra.is_open()) {
       // do something to get bank, e.g. fetch it from database
       qtra.reopen();                  // perform again nlink ("QTRA", 0)
    }
  } 

Should the "row" class contain a default name and number of a bank?

  void f () {
    Table dtra (); // open "DTRA" bank with number 0
  } 

  // file dstbanks.h
  class BankDescriptor {
  public:
    static char name [5];
    static int number;
  };
    
  class dtrarow: public BankDescriptor {
  public:
    float ptinv_tr;
    // and all the rest...
  };
  

  // file banks.h
  template  
  class Table: public Bank {
  public:
    Table (): Bank (row::name, row::number) {
      // check miniheader;
    }
  // and all the rest...
  };
  

  // file dstbanks.C
  #include"banks.h"
  #include"dstbanks.h"
  
  dtrarow::name   = "DTRA";
  dtrarow::number = 0;
  

Banks with wrong format

"Free format" list-like banks

Use of int32 and float32

  typedef int32 int;
  typedef float32 float;
  

Garbage collection

• The FORTRAN "solution":
  Simply demand that no bank indices are reused after garbage collection. In the C++ case this means that during garbage collection no Bank object must be in scope.
  This solution is not as silly as it seems:
  Practically no user ever calls the garbage collector herself. This is normally done only by FSEQR and MODULF. Since the only allowed communication between modules is by banks, not by variables (and bank indices are variables), no problem arises.
• Perform some check at every bank access, e.g. check that the stored bank name is equal to the contents of iw[base-4].
  This is certainly too slow and (I think) ugly.
• Don't store the bank index at all, but store name and number of the desired bank, and always perform an "nlink" to access the bank.
  This option is probably the safest, but surely too slow for practical purposes.
• Fast version of the last solution:
  Probably the slowest step in "nlink" is the lookup of the name, i.e. evaluation of IW(NAMIND("BANK")). But the result of NAMIND("BANK") is guaranteed not to change during a program, even after garbage collection, so it can be safely stored.
  Then an undocumented entry into NLINK, namely NLINC, can apparently be used to get the actual link to the desired bank. Since in most cases the bank with the lowest number is wanted by the user, i.e. the bank given by IW(NAMIND("BANK")), this is bound to be very fast.
  Actually, one could provide means to "allow" the class to use IW(NAMIND("BANK")) instead of NLINC(NAMIND("BANK"), 0) in cases where this is thought to be safe (e.g. DST banks).

Work banks

Database banks