org.vishia.java2C
Class Docu.C_StaticDataOfConversion

java.lang.Object
  org.vishia.java2C.Docu.C_StaticDataOfConversion

Enclosing class:

Docu

public class Docu.C_StaticDataOfConversion
extends java.lang.Object

While the translation processes the type or affiliation of some identifiers should be evaluated. In java this is done by the javac-Compiler. In C some more informations should be appropriated to the C-Compiler. Therefore all identifiers are stored in Lists. This lists are TreeMap mostly to support a fast searching.

Docu.C_StaticDataOfConversion

public Docu.C_StaticDataOfConversion()

B1_LocalIdents

void B1_LocalIdents()

LocalIdents
Identifiers are valid always in a local context. This context may be a class context, a method context or a context of a statement block (some statements in {...}). The class LocalIdents holds references to identifiers and types, with some add- and access methods, for all the contexts:

• StatementBlock.localIdents: for any statement block.
• ClassData.classLevelIdents for the class level context.
• JavaSrcTreePkg.pkgIdents for the idents, which are associated to packages-local classes respectively files.
• GenerateFile.fileLevelIdents: All visible types while translation a file are stored here. It are a copy from the JavaSrcTreePkg.pkgIdents of the current package, the same one form all imported packages and all imported class types. This LocalIdents are assembled for translating a file running first and second passes. This LocalIdents aren't be visible or used while accessing any classes from outside.
• Method.methodIdents: The methodIdents are the LocalIdents visible at start of body of the method. It contains the parameter of the method especially. The body's LocalIdents is created as an own instance than, because it is handled like an normal StatementBlock.
• CRuntimeJavalikeClassData.stdTypes This referenced instance contains the global visible types. It contains
  • the C-language standard types int etc.,
  • all packages visible at root of packages,
  • all types from package java.lang, mostly implemented in CRuntimeJavalike-C-environment.
  This instance is the JavaSrcTreePkg.pkgIdents of the JavaSrcTreePkg-instance for java.lang.

The LocalIdents contains TreeMaps for

• LocalIdents.fieldIdents identifier of all variables in this context. Especially in statement block some variable may be defined, they aren't known in the class context.
• LocalIdents.typeIdents identifier of all types in this context. In a statement block local visible classes (defined in the block) are possible too.
• Method identifications are not contained there, they are hold in Class context, see ClassData.methods respectively ClassData#searchMethod(String, java.util.List, boolean).

An instance of LocalIdents in any scope contains all field and type identifiers from the super (parent) scope too as a copy of the identifier Strings and references from the parents TreeMaps. To prevent effort, In StatementBlock a new LocalIdents is created only with the first definition of an type or variable. But the types of the standard language level, it is CRuntimeJavalikeClassData.stdTypes,isn't copy to prevent effort. It contains only types and the root packages. Therefore searching of types (see LocalIdents.getTypeInfo(String, LocalIdents)) should regard three locations:

• The LocalIdents of the given local scope, it contains inner classes and classes defined in a statement block (rarely used in practice),
• The file level LocalIdents, given as extra parameter because it depends from the file to generate. This LocalIdents contains the package level LocalIdents of the own package too, and with them the own Class. Especially imported classes are contained there additionally.
• The standard language idents given in the static CRuntimeJavalikeClassData.stdTypes.

The searching of a identifier uses always the Java name of identifier. In the found FieldData than the C name is contained.

B2_identifiersForOuterOrSuperLevels

void B2_identifiersForOuterOrSuperLevels()

Identifiers of super and outer levels
Super levels are the levels above a statement block;

• the parent statement block,
• the whole method,
• the class
• the super class and the outer class
• the super.super class etc, the outer.outer class etc.
• All global visible identifiers: Java2C_Main#userTypes and Java2C_Main#stdTypes

In generally, there may be two ways to search identifiers of super levels:

1. An instance of LocalIdents contains only the identifiers of the current level. It contains a reference to the super and outer LocalIdents. Than the searching process is lengthy, if a identifier isn't found locally, it should be searched in the next super and outer level and so on.
2. An instance of LocalIdents contains all identifiers visible at this level. If a new instance of LocalIdents is created, the identifiers of the parent level should be copied and designated with its context oriented from the current level. This copy process necessitates some calculation time, but only one time per new level. Some more memory spaces is needed, but only temporary (the garbage collector have to be tidy up). But the searching is simple and fast.

The solution is:

• fields, variables are contained complete in the current LocalIdents.fieldIdents. If a new level of statement block is created, first the reference to the LocalIdents of the super level is set. But if any block-local variable is found (calling GenerateClass#gen_variableDefinition(org.vishia.zbnf.ZbnfParseResultItem, org.vishia.zbnf.ZbnfParseResultItem, LocalIdents, java.util.List, char)), a new instance of LocalIdents is created and all fieldIdent of the parent are copied into it. So any instance of LocalIdents contains all visible identifier of variables and class fields. The association is stored in the FieldData.
• Types of a inner level starting from Class level (ClassData.classLevelIdents) are contained complete in the current LocalIdents.fieldIdents too. But Language Level types are found in CRuntimeJavalikeClassData.stdTypes. Third, all imported classes and the classes of the own package are found in the GenerateFile.fileLevelIdents. Therefore to find out a type three search operations should be do.
• Methods are stored only in the accordingly instance of ClassData. If methods from the super classes are searched, the search operation is called for all super-classes. The adequate problem is for interfaces and outer classes. TODO: It may be opportune to copy the methods in one TreeMap too.

The knowledge of field-identifiers and types of the outer classes and the sibling- inner classes in inner classes and the knowledge of this one of the super classes in the derived classes is an adequate topic. But additionally the field-idents should be designated as outer or super ones. That designation is contained in the fields FieldData.nClassLevel and FieldData.nOuterLevel. See Docu.E_Inner_classes.

B3_searchMethodIdentifier

void B3_searchMethodIdentifier()

searching a method identifier with parameters
Methods can't defined in a local context, only at class level. To know and search methods in the actual context, the ClassData of the appropriate class of the local context can be used. They are access-able in the methods of SecondPass via GenerateClass.classData See #methodCall_WithParameterSensitivity()

B4_InstancesWhichContainsStaticData

public void B4_InstancesWhichContainsStaticData()

ClassData
That are the type informations. The ClassData are referenced in LocalIdents.typeIdents. Classes have their own ClassData.classLevelIdents.

FieldData
That are the variable and field informations. The FieldData are referenced in LocalIdents.fieldIdents. Fields based on FieldData.typeClazz, but have some additional properties, also especially for the C-Code-representation. Also arrays with theire special properties are considered.

CCodeData
That are peaces of C-Code with its type-information CCodeData.identInfo, but also special properties. If an array element is addressed from a array-field, it may be possible to store the access information in an extra CCodeData.identInfo. But the solution is: The FieldData of the whole array is referenced, and the access properties to the array element are stored in extra data fields: CCodeData.dimensionArrayOrFixSize and CCodeData.modeAccess of the element.