From the earliest days of BBSIM a dual language (Fortran and C++) environment was part of the design and an eventual migration to C++ was foreseen. This was motivated by BaBar's intent from its inception to pursue an eventual C++-based object oriented software environment. Recognizing that manpower would be perpetually in short supply, an important goal was to support a dual language environment that imposed minimal additional coding burden over and above coding for Fortran only. Dual language support was first addressed in a tool developed to serve as a geometry database for the simulation during the detector design stage. A simple ascii file based database supporting structured data and replicated data types (multiple instances of structures) was required to support human editing of database files for the subsystems, building up a detector description from detector parameters as obtained from engineering. The system had to provide very flexible and low-overhead means of changing parameters (both changing values and adding new parameters) to support the tracking in the simulation of a rapidly evolving design and design optimization studies requiring variation of parameters. The system had to be simple enough so as not to provide a barrier to use and thereby an incentive to hardwire parameters into the code (a no-no). Available tools such as the TZ package of CERN were rejected because of their complexity, high programming overhead and lack of dual language support.

BaBar's solution was to develop an in-house package, dbin, providing single-instance data structures such as

structure muon         ! muon detector/flux return parameters
  char  bname "MBAR"   ! mu barrel
  int beamline 0       ! obsolete
  int nphi 6           ! number of phi sectors
  real ip     -37.0    ! distance from IP to IFR centerline
  real brin   182.0    ! inner barrel radius
  real brout   -1.0    ! outer barrel radius. Filled in code.
  real blen   405.0    ! barrel length
  int ngrades 4                ! number of plate thickness gradations
  int npltb(4) 9 4 3 2         ! no. of barrel plates
  int     stripnumpxl(2) 1  96   ! 1st, offset, last, strip number in the forward, x view
  real fact(13)     /
   1.e3  1.e3 1.e3  1.e3 1.e3 1.e3   10. 1.e3  1.e9  10.   10.   100.   1.
end muon

supporting, as indicated, the basic data types and simple arrays, and multiple-instance structures ('templates') such as

template bpmat    ! bpip materials template (material no. assigned in bp_tmed)
   int number     ! material number - reassigned dynamically in bp_tmed
   char name      ! name
   real a         ! atomic weight 
   real z         ! atomic number
   real dens      ! density           (g/cm**3)
   real radl      ! radiation length  (input g/cm**2, converted to cm)
   real absl      ! absorption length (input g/cm**2, converted to cm)
end bpmat

make bpmat gld  0 "goldmask" 196.97 79.00  19.3     6.46 212.3
make bpmat wtr  0 "water"    18.    10.     1.0    36.08  84.9
make bpmat car  0 "bp-cfib"  13.208  6.600  1.590  24.9   63.6

The database file defines simultaneously the structure of the data and the data values.

The original implementation of the database utility, dbin, has been replaced by dbio which extends the functionality in ways which will be discussed. The two programs presently coexist in the software as we are migrating to dbio. From this point for the sake of consistency we will henceforth refer only to dbio.

The dbio program parses the database files (a hierarchy of files supported via an 'include' directive, such that database sections for different subsystems can be maintained separately) and generates code as output:

an initialization routine which sets all database values to the values they had in the db files when dbio was run (ie. sets default values)
a runtime database read routine which can parse database files at runtime and read and set parameter values (ie. runtime overrides of the defaults)
include files providing access to the database parameters from user code.
other files associated with I/O and C++ class definition discussed elsewhere

All this code is generated both in Fortran and C (C++) versions. The generated code represents all the code needed to read and access the database; thus there is zero coding overhead when building or modifying a database, and no additional coding burden is imposed to make use of the database in C++ as well as Fortran.

All BBSIM detector geometries define their parameters via dbio databases, so that now as we proceed with the implementation of a C++ Geant4 simulation, we have the full geometry database available to our C++ codes with guaranteed consistency with the BBSIM version because the root source of the data in both cases is a set of common, language independent ascii database files.

The C++ code generation was in fact put to use from the beginning, as a number of the BBSIM geometry codes were written in C++ using the 'euclid' package described elsewhere.

The system has worked very effectively and proven popular, which has led to its extension to other application domains associated with data management in a dual-language environment.

Data structure definition

A weakness of the original implementation of dbio was that the data spaces in memory set up by the autogenerated Fortran and C++ code were different; Fortran code accessing a particular parameter accessed a different memory location than C++ code accessing the same parameter. It was impossible to overlay the data spaces in memory because the representations were different; the Fortran implementation used arrays of standard types, not user-defined types (structures) as would be necessary to map to the C++ structures used in the C++ implementation. A further problem was the use of HepString for the string implementation in the C++ code. Thus while dbio provided dual-language support to distinct Fortran and C++ codes, it did not provide dual-language support within a single program (easy access to a common structured data space). This was regarded as necessary in the simulation to support a migration path from Fortran to C++ that takes the approach of coding now in C++ and using the code in Fortran. We needed a way to define and implement data structures to provide such an interface across languages, and across programs (eg. to support output from the Fortran simulation in a form readily readable by C++ digitization and reconstruction code).

Important extensions to dbio made in the context of work outside BaBar (on Fermilab's MCFast project) provided the means whereby data structures could be defined using dbio to interface between C++ and Fortran routines and programs. The Fortran implementation was modified to use extended VMS-style structures (not used in the original implementation because of concerns, since alleviated, that they would not be available on all platforms) and the C++ implementation was converted to C with the use of HepString replaced with char arrays such that (as has been verified on all platforms) the Fortran and C data spaces for a given structure are identical. The code was modified to overlay the data spaces in memory such that Fortran and C/C++ references now access the same data space. [incomplete!]