18. MULTI USER MODE

18.1 Central Database
18.2 Several Levels of Data
18.3 Co-existing Independant Projects

OrgC++ may be used simultaneously at several levels for more complicated projects. The rules are simple:

  1. Each level controls its own objects. ZZ_HYPER_ declarations must be in the same file where their objects are declared. Exceptions: GENERAL_LINK and SINGLE_LINK may point across levels.
  2. Subprojects may use the objects and organizations of the projects above them.
  3. For each subproject, the class generator must run on a file that combines all ZZ_statements from that level up.
  4. SELF_ID can be declared only at the highest level.

There are three basic styles of using OrgC++ on large projects.

Chap. 18.1describes the situation where OrgC++ is used to design and control a central database used by many programmers, who use OrgC++ calls to access the database, but not for their private data.

Chap. 18.2 shows a general case, where OrgC++ is used for the central database and for private data by individual programmers.

Chap. 18.3 deals with several independent OrgC++ projects that must co-exist without interference under a large project.

18.1 Central Database

Let us assume that we want to use OrgC++ to design and control a central database. Peggy, who is the database manager, will keep class declarations in a special include file called, for example, database.h.

We assume that Peggy will keep all database files in the database directory; nobody except Peggy will have write access to that directory.

After declaring the data and its organization through ZZ_HYPER_ statements, Peggy will run the class generator: orgC/zzprep database.h. That will create the database/ZZinclude.h file.

All programmers using the database will include in their programs:

#include "database/ZZinclude.h"
#include "database/database.h"

They will be able to access the central database through OrgC++ calls without even calling the class generator.

Peggy will have to run the class generator any time that the data definition or organization has changed.

18.2 Several Levels of Data

The orgC/test/multi directory contains an example, which demonstrates how to handle a multilevel project in a variety of situations. A script to run this test is included as a part of the standard regression test, see test/cregr for the SUN C++ compiler, or test\b4pregr.bat for Borland C++.

The project involves the following people and directories:

project leader, directory: main, files: main.c proj.h
John, directory: jDir, files: j1.c j2.c
Susan, directory: sDir, files: s1.c s2.c s3.c sIncl.h
Peter, directory: pDir, files: p.c

The definition of objects (structures) common to the whole project is in the proj.h file which also contains all ZZ_EXT_... and ZZ_HYPER_... statements common to the whole project.

John is not using any additional organization of data; his programs operate only on common data.

In addition to common data, Susan sets up her own temporary organization of data. The additional ZZ_EXT_... and ZZ_HYPER_... references are in her sIncl.h file.

Peter also uses some additional data structures, but since all his programs are in one file, he does not use a separate header file. All his ZZ... references are in the p.c file.

The compilation and linking sequence is:

  1. Project leader runs zzprep on proj.h. This creates ZZinclude.h in the main directory. 
  2. Now all three programmers can develop and debug their programs independently. John just uses main/ZZinclude.h, because he works with global data only. Susan combines proj.h and sIncl.h and runs them through zzprep. That creates her own ZZinclude.h, which covers both global data and her own. Peter does the same thing, except that his case is simpler because he has only one file.
  3. When the three programmers have their programs ready, they create library files, one in each directory.
  4. The project leader compiles main.c, and links the whole project together. She must also link it to the OrgC library.

18.3 Co-existing independent projects

Sometimes it happens that, inside a large project such as a telephone switching system or a CAD system for VLSI chips, several programmers want to use the OrgC++ library for their part of the project, while individual data sets are completely independent.

An example of such a situation is the implementation of the PAGER in the OrgC++ library. It is implemented with the OrgC library [it has its own private data in file lib/pager.hpp], but when you link your application to the library, you don't even know about it.

One possibility is to use ZZ_LOCAL_.. instead of ZZ_HYPER_.. declarations, and hide the entire implementation inside a special class which encapsulates the whole subproject (see Chap.8.5 on how to use ZZ_LOCAL_..).

The second possibility is to use #define ZZ_LOCAL instead of #define ZZmain. The names are similar, but there is a vast difference between

#define ZZ_LOCAL

and

class Employee;
ZZ_LOCAL(myRing,Employee,Employee);

#define ZZ_LOCAL makes all OrgC++ internal type tables and global control variables static. This is the method used internally in our library to implement the pager. The current drawback is (and I believe this is only a temporary limitation) that such a subproject cannot save/retrieve data from disk.

 

Chapter 17: Merging and Reducing Libraries Chapter 19: Revision History