From lechner@cs.uml.edu  Sun Feb 12 18:13:51 2006
From: Bob Lechner <lechner@cs.uml.edu>
Subject: Please take a look at $PH/COOL-BDE/bdegencpp/gencpp_ghostvars.051121.txt
To: ralmonte@cs.uml.edu (Almonte)
Cc: lechner@cs.uml.edu (Bob Lechner), sfrye@cs.uml.edu (Scot Frye)
RJLRef: $PH/COOL-GEN/gencppGvarsMapping060212.txt

$PH/COOL-BDE/bdegencpp/gencpp_ghostvars.051121.txt
is a proposal to extend gencpp (eventually) along
the lines of the SWF text toward generic and
auto-generated 'mapping transformations' between 
app revisions based on two versions of schema.sch.

I would not dare to conjecture that this would 
help my current quandary about just when bde should 
be ported from chgen to gencpp. I do believe it would
help later schema evolution after bde runs with gencpp.

Right now (and for tne near future) I can't access 
whether Robert should work on bde2fox ASSUMING that
bde/pr_util comes from gencpp. I do believe he should 
look at the gencpp report of KMiu/MOttesen :
$CASE/gen/gencpp/ver_1/doc/gencppFinalReport_km_mo_rl051027.doc
with the goal of avoiding design decisions
that will make it more difficult to port bde 
to gencpp's pr_util in the future.


Gencpp's new pr_util architecture is concerned with
database management so it should not affect 
the view/controller/GUI side of bde at all.
However, it makes each entity object a row-class
not a row-struct (e.g., class HG not struct HG)
so it affects address expressions.

For example, gencpp produces a .h file and .c file 
for every entity class in schema.sch.
However, to retain compatibility it also generates
static methods in pr_util that handle all tables,
like pr_load and pr_dump.

Almonte might be able to use or  adapt gencpp access methods 
(as was done in chgen113 to produce bde/pr_util/pr_accessors.c)
or specify how they can be adapted to his needs.

gencpp generates pr_util conditionally, based on a compile-time 
option, into EITHER a STL-container-based version of 
memory-resident database tables
OR into bde/pr_util's current intrusive list container style.
The idea was to permit a minimal-change port of bde to
a gencpp-based pr_util  that retained intrusive lists 
in old bde style, then a second port if warranted 
from intrusive lists to STL-containers.
STL Vectors are fine for maintaining entire tables,

But I no longer believe in STL containers for parent-child 
lists: there are far too many of these (one for each 
parent role of every non-leaf object instance: imagine the
XB ---> TK child-list from lexical analysis of every text 
line (HA, GX, HI) and the SYmbol-->TK child-lists  
that produce cross-reference listings. For each such parent
instance, pr_load must create a separate STL container 
if intrusive lists are replaced by gencpp's USE_STL style.

The test-case example of gencpp use with STL containers  
for a simpler schema test_co_pr.sch is at:
-------------------------------
saturn.cs.uml.edu(143)> lg $CASE/gen/gencpp/ver_1/aareadme
-rw-r--r--   1 lechner  fac         3673 Nov  2 21:22 /usr/proj3/case/gen/gencpp/ver_1/aareadme
saturn.cs.uml.edu(144)> ls -f $CASE/gen/gencpp/ver_1/test
.                 test_co_pr.sch    pr_dump.cc        EMops.cc          COschema.h
..                test_co_pr.vdf    pr_free.cc        ONschema.h        COops.cc
CVS               test_results.out  pr_delete.cc      ONops.cc          PRschema.h
test_co_pr.cc     test_co_pr.h      pr_stats.cc       DEschema.h        PRops.cc
test_co_pr.dat    pr_load.cc        EMschema.h        DEops.cc
-----------------------------

I have a 4-way comparison of gencpp with/without STL somewhere.
Some bde/pr_util  size comparisons  are discussed in
$PH/COOL-GEN/gencpp/gencppComparison/testgenv12bde/aareadme_testgenv12bde
The $CASE/03f522/bdegencpp03f project was a start but did not add  much value.