|
|
1.1 ! root 1: ! 2: 8 November 1989 ! 3: ! 4: This file describes the content of the version of cfront prepared at ! 5: ODI for transmission to AT&T. ! 6: ! 7: DESCRIPTION ! 8: ! 9: The version of cfront in this directory is a subset of the current ! 10: development version of cfront at Object Design, Inc. Its primary ! 11: purpose is to implement parameterized types. However, it includes a ! 12: few other changes. ! 13: ! 14: The precise content of this version is a compromise between two goals. ! 15: The first goal was to make a compiler with parameterized types ! 16: containing as little different as possible from 2.00. The second goal ! 17: was to make a compiler that we were substantially confident introduced ! 18: no bugs, either in the parameterized type area proper or in the rest ! 19: of the language. ! 20: ! 21: It would be very difficuly to demonstrate that a particular bug fix is ! 22: not required for the template facility. Therefore, this version ! 23: includes all of the bugfixes and imnprovements to low-level substrate ! 24: that were either directly needed by parameterized types or difficult ! 25: to remove without risk of breaking them. ! 26: ! 27: The major changes from 2.0 are listed here. Detailed descriptions of ! 28: bug fixes are supplied in the file BUGFIXES. ! 29: ! 30: CHANGES ! 31: ! 32: 1- Substrate and Debugging Support ! 33: ! 34: a- tree walking and copying ! 35: ! 36: The parameterized type implementation depends on the ability to apply ! 37: an procedure to each node of a tree resulting from syn() in order to ! 38: copy it, applying the parameterization. The tree walker supplies this ! 39: functionality. tree_walk.c and tree_walk.H contain the tree walker. ! 40: ! 41: In order to for the tree walker to work, it must be able to determine ! 42: by examination which fields of any given nodes contains nodes that ! 43: need to be walked further, and which contain other quantities. In ! 44: 2.00, several unions punned storage between nodes and other things in ! 45: ways that were difficult or impossible to disambiguate by examination ! 46: of the node in question. Therefore, we added some new fields to nodes ! 47: in order to remove these ambiguities. We also changes some auxiliary ! 48: structures to be based on node so that the tree walker could process ! 49: them. ! 50: ! 51: The tree walker uses the "discriminator" member functions of the ! 52: various nodes with unions. These functions take a node and a union ! 53: index and return an index identifying a particular union member. ! 54: In fact, this is more information that the walker needs, since once it ! 55: knows that a field contains a pointer to a subtype of node it can tell ! 56: what kind of node it is by examining the base. ! 57: ! 58: The walker needs to know which base values correspond to which ! 59: structures. node_classes.H records that information. ! 60: ! 61: The tree copyier is an application of the tree walker that copies a ! 62: syn() tree. It is used directly by the template implementation. ! 63: ! 64: b- tree dumping ! 65: ! 66: Another application of the tree walker is the tree dumper. It displays ! 67: the tree symbolically, and can handle dcl processed trees. It is built ! 68: to be runnable either in cfront or in a debugger. At ODI, our debugger ! 69: has a command to print cfront nodes that makes use of this. ! 70: ! 71: The +OTfile control argument to cfront causes a dump of the syn() tree ! 72: for each top level item in turn. ! 73: ! 74: c- storage management ! 75: ! 76: There are three changes to storage management. First, the ! 77: constructors that assign to this are replaced by new and delete ! 78: operators. We found this made it much easier to set breakpoints to ! 79: discover where nodes were deleted inappropriately. ! 80: ! 81: Second, no storage is recycled during the compilation of one top level ! 82: item. Deleted nodes are accumulated on the free list until the end of ! 83: the current top level item, and then are made available to the next ! 84: one. This reduces greatly the impact of misplaced uses of delete, and ! 85: leaves many more tracks of problems that would otherwise be written ! 86: over by node reuse. ! 87: ! 88: Finally, the +OD option forces runtime checking at a few critical ! 89: places for processing of a node which has already been deleted. ! 90: ! 91: 2- Parameterized Types ! 92: ! 93: <Sam should insert a description here> ! 94: ! 95: 3- limit_renaming ! 96: ! 97: <rick can improve this I hope> ! 98: ! 99: To make debugging of c++ programs easier, ODI added a mode of ! 100: operation to cfront that makes the variable names in the generated C ! 101: code correspond much more closely to the variable names in the c++ ! 102: code. ! 103: ! 104: In a modern C compiler (such as Sun's), there is no need for the __N ! 105: tags on scalar variables or the structure name tags on structure ! 106: elements. The +Ogx argument to cfront removes these and other ! 107: unneccessary renamings, making the resulting code much easier to read. ! 108: ! 109: 4- constant enforcement ! 110: ! 111: This version of cfront enforced const in all cases that we have been ! 112: able to test. In particular, ! 113: ! 114: struct C{ ! 115: int x; ! 116: }; ! 117: ! 118: const C c; ! 119: ! 120: c.x = 1; ! 121: ! 122: is an error as it should be. ! 123: ! 124: The implementation strategy is to propagate const up the expr tree ! 125: from DOT operators as needed. ! 126:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.