Constructor Detail

• Docu.F_Translation_Secondpass

  public Docu.F_Translation_Secondpass()

Method Detail

• f1_referencesOrEnvironmentTypes

  public void f1_referencesOrEnvironmentTypes()

  In Java a environment-type for a static method and a reference of a dynamic method are not differenced. Both are written with a dot as separator:

   Arrays.binarySearch(..) //an example of static method of class Arrays
   myInstance.method(...)  //a normal class method call.
   

  The difference is detectable only searching the identifier in translator tables. Therefore the identifier is tested in the method in StatementBlock#gen_reference(String[], ZbnfParseResultItem, LocalIdents, char, IdentInfos[] retIdentInfo). The got association String from ZBNF-parse-result is tested calling LocalIdents.getType(String, LocalIdents) in the given local environment. It includes especially standard types, but also local types in the class definition and the file-level types (package and import). If the association String is recognized as Type, the associated type is used in the next reference levels respectively it is returned in parameter retIdent. Because that type is the base type info for searching the referenced identifier, the method calls in C are translated with the name_Type-info.

• f2_casting

  public void f2_casting()

  There are four types of castings, it is the combination of

  • implicitly or explicitly casts,
  • casts of scalar types (int etc) or reference types.

  The casts of scalar types is equal in C and Java: Cast to a type with higher precision may be implicitly, the cast to a type with less precision need s a explicitly cast. In Java it is necessary, in C it is a warning of compiler mostly, but it should done.
  
  The casts of reference types may be separated in two cases:

  • downcast: From a class to a super class or interface.
  • upcast: From a interface or super type to a derived type.

  The downcast may be implicit or explicit written in Java, both is correct. The compiler knows all possibilities of down-casting, tests and accepts it. In C a downcast have to be programmed with an access to the correct and given super class or interface. A simple pointer cast is the second properly variant. A pointer cast is always a possible sourse of errors. Therefore it should be avoid to use if it isn't necessary. An access to a super class can be write with &ref->base.super.base.super instead an equivalent (SuperType*)(ref). The machine code is equal for both variants.
  
  A upcast is written explicitly also in Java. A upcast is correct if a reference given as super-class or interface reference references really a instance which is from the casted type. In Java a runtime check is execute. The demand of upcast from programmer is an assumption. Therefore it should be done explicitely. In C the adequate construct should be a cast also. Another way of solution isn't able. But the C runtime doesn't check the legitimacy of that cast. A goal to explain the cast in a safety software check session is, the code is tested in Java. Another possibility may be, also execute a instance type test. The second decision needs some calculation time, it's the same problem as check the array indices for IndexOutOfBoundsException. The decision in Java2C for this problem is: If a failed access is able to assume, the programmer should be write a instance type test in Java explicitly. It is assert(ref instance of Type);. It will be translated and executed in C too, and it is conspicuously and should sufficing for a safety software check.
  
  For Java2C-translation the check of cast-ability and the production of a cast expression is necessary for some cases:

  • Check of type compatibleness for arguments of methods: See #methodCall_WithParameterSensitivity(). it should be tested if a given argument is matching to formal argument types. The method ClassData.matchedToTypeSrc(ClassData) is provided for such check.
  • Production of explicitly casts where Java allows an implicitly cast.

  Another problem is the adaption of access. In Java only either primitive types or references are addressed in a variable or with an expression. In C at least the embedded instances needs a special handling, the reference operator &ref->embeddedInstance. Additionally there are some special cases like a StringJc or OS_TimeStamp, which are taken as value arguments and returned as values in methods.
  
  cast of an expression:
  The method FieldData.testAndcast(CCodeData, char) produces the correct expression with given C-code including type and access mode of it in respect to a given field-type-description. It is used at any assignments: method arguments, return value preparation and value assignments. At example in Java it is coded ref-embeddedInstance, but a parameter or destination variable is of an base or interface type. Than the method returns the necessary adaption for C language in form &(ref->embeddedInstance.base.IfcType).
  
  cast of the access:
  The method FieldData.testAndChangeAccess(char, String, char) produces the correct expression if only an access should be changed.
  
  cast of an assignment:
  See StatementBlock.gen_AssignCheckCast(CCodeData, String, CCodeData).
  
  The methods ClassData.addCastFromType(ClassData, String, String) and ClassData.addCastToType(ClassData, String, String) adds a possibility of cast to the a class. It is used explicitely for standard types, but also for declaring the possibility of access super and interface types, see Docu.SuperClassesAndInterfaces. It is called inside ClassData.fillMethodsOverrideable(ClassData.InheritanceInfo inheritanceInfo, String sPathToMtbl, String sPathToBase)

• f3_methodCall_WithParameterSensitivity

  public void f3_methodCall_WithParameterSensitivity()

  Methods in Java are parameter sensitive. This feature is known also as overloading of methods. It means, that an method of class StringBuilder append(int value) is another method as append(String value). It is clear for Java users. Okay. In C++ it is the same concept.
  
  But in C, the methods should have an unambiguously name. Therefore, the same steps have to be done which were done by a javac-compiler:

  • Ascertaining the type of all parameters of method call.
  • Searching the appropriate method variant in the environment class, where the method is member of.
  • If no appropriate method is found, variation of the type of parameters to their generalized types, it means int from short, long from int or float from int etc., but also detection of super classes and interface types of references. Search again.
  • Building the C-like method name in a special style, considering the parameter types and the environment class name.

  This steps are done in Java2C-translation time. The result is visible in the generated C-code. This steps are done only if ambiguously method with the same names are exist. If only unambiguously method names in one class are given, a simple rule is used to build an unambiguously method name common spanned: methodname_classname.
  
  
  For some lang and util-classes the methods have their fix names in the [[CRuntimeJavalike]]-C-Library, that is also useable for C-level-programming. Thats why, and also to support a testing at C-level the names of methods considering parameter types should be shortly, readable and understandable
  
  The translation of Java method name plus parameter types to that C- method names are given in a translation table. There is no common fix rule to built it. But for method names of the users Java code to translate to C a rule is given.
  
  The following things are implemented in the Java2C-Translator:

  • The type of arguments in the method call is detect calling StatementBlock#gen_value(ZbnfParseResultItem, char). The type is returned in its CCodeData-return data. The type of a value is build from
    • The type of a variable, returned from StatementBlock#gen_variable(org.vishia.zbnf.ZbnfParseResultItem, LocalIdents, char, CCodeData) CCodeData-return data.
    • The type of a constant value, returned from retType in GenerateClass#genConstantValue(org.vishia.zbnf.ZbnfParseResultItem). The type of the constant value is detect while parsing the Java source code. The type of a numeric value is detect additional by testing the value range of the number. Especially the type of an string literal in "string" is designated as Java2C_Main.CRuntimeJavalikeClassData#clazz_s0. The s0 means, C-like 0-terminated string. It is a special case of a String represented by { Java2C_Main.CRuntimeJavalikeClassData#clazzStringJc.
    • The type of a method is the return type. It is supplied in argument retType in StatementBlock#gen_simpleMethodCall(org.vishia.zbnf.ZbnfParseResultItem, CCodeData, LocalIdents).
    • The type of a new Object is returned in retTypeValue from StatementBlock#gen_newObject(org.vishia.zbnf.ZbnfParseResultItem, LocalIdents) or StatementBlock#gen_newArray(org.vishia.zbnf.ZbnfParseResultItem, ClassData[], LocalIdents).
  • Both a method call and a constructor is translated using StatementBlock#gen_simpleMethodCall(org.vishia.zbnf.ZbnfParseResultItem, CCodeData, LocalIdents). While translating the actual parameters are read from the ZbnfParseResultItem. The values are generated calling StatementBlock#gen_value(org.vishia.zbnf.ZbnfParseResultItem, char). This method returns the type of the parameters. The types are used to search the method.
  • To search the method ClassData#searchMethod(String sNameJava, java.util.List paramsType) is called with the ClassData-instance of the environment type. That is the type of the instance in Java left from point of method call. This ClassData are referenced from the parameter envInstanceInfo of gen_simpleMethodCall(). If the environment instance is this, the envInstanceInfo came from ClassData.classTypeInfo of the own ClassData-Instance.
    • The method is searched first with their number of arguments. It is possible that they are more as one ambiguous method with the same name and the same number of arguments. If there is only one method, its okay and unambiguous. Otherwise the types of the arguments are tested now.
    • If the types are matched directly, its okay. Elsewhere the routine ClassData.matchedToTypeSrc(ClassData) arbitrates whether the type is compatible. Than it is possible that a cast expression is necessary in C, without though an automatic casting in Java is done. The cast expression is generated in StatementBlock#gen_simpleMethodCall(org.vishia.zbnf.ZbnfParseResultItem, CCodeData, LocalIdents).
  • The method translating tables from Java-name + parameter types to C-name are created for the CRuntimeJavalike-methods in Java2C_Main.CRuntimeJavalikeClassData - constructor. It is hand-made.
  • The method translating tables for translating classes will be created and filled while executing FirstPass#runFirstPassFile(String, org.vishia.zbnf.ZbnfParseResultItem, String, ClassData, java.util.List, LocalIdents).
    • Before any other translation occurs, for all methods of the class, ClassData.testAndSetAmbiguousnessOfMethod(String) is called with the java name of the method. If more as one method with the same name is found, the method name is ambiguous. Only than a complex method name for C should be built.
    • The methods are registered in first pass calling FirstPass#wrwrite_methodDeclaration(ZbnfParseResultItem parent, String sClassName, LocalIdents. In this routine it is known whether or not the method is ambiguous, because all methods are tested before.
    • From there FirstPass#gen_methodHeadAndRegisterMethod(org.vishia.zbnf.ZbnfParseResultItem, String, String, FieldData, boolean), is called. In this routine the C-method-name is build either with argument-type-naming parts or not. The argument-type-naming parts of the C-method-name are simple chars for standard types, see registration of standard types in Java2C_Main.CRuntimeJavalikeClassData, calling the constructor of ClassData#ClassData(String, String, String, String, String). A short name for user-Type-arguments is built with prominent chars of the type, testing its unambiguously in global scope.
    • With that built C-Name and the argument types the method is registered in ClassData calling ClassData#addMethod(String, String, FieldData, FieldData[]).

• f4_methodCallWithVariableArguments

  public void f4_methodCallWithVariableArguments()

  Variable arguments are known both in Java and in C. In C the handling of variable arguments is more simple-primitive. The type of the arguments should be described somewhere else. The typical known application of them is printf. Hereby the type of arguments are described in the printf-text combined with the format specification, at example printf("values: %3.3f, %4d\n", floatValue, intValue);. It is classic. Because the type of values may not correct (float or double, long, short), the compiler may convert a float value in double etc. to prevent errors. The originally idea was to determine the fine specification of the type with modifiers such as %3hd for short. But already float and double are not possible to difference. Some compilers operates variedly. That is C/C++.
  
  In Java the problem of a printf-like formatting is some more separated from the variable argument handling. Variable arguments are accepted as array of the same types. Because any complex type can downcast to the base Type Object, and any simple type has a representation as Object (int as class Integer etc.), any argument can be provided as an Object:

     method(Object ...){...} //declaration of a method
     method(5, 3.4, intVal, classInstance); //call of method.
   

  Java2C generated a type String as argument before a variable argument list in any case. The type String contains the detect type of any actual argument as one letter. Especially the primitive and some Standard types are detect in this way. All complex types are supplied as ObjectJc. Therefore the method from example above has the following representation in C:

     method(char const* typeArgs, ...);   //declaration of method
     method("IDIL", 5, 3.4, intVal, classInstance); //call
   

  ...TODO

• f5_methodCallFromSuperClasses

  public void f5_methodCallFromSuperClasses()

• f6_methodCallFromOuterClasses

  public void f6_methodCallFromOuterClasses()

• f7_constructorCall

  public void f7_constructorCall()

  A constructor is either a static method of the associated class, or it is understand as a non-static method of the outer class, if the class is an non-static inner class. The constructor is searched calling ClassData#searchMethod(String, java.util.List, boolean), where the name is

  • "ctorO" for a static constructor with a class based on Object,
  • "ctorM" for a static constructor with a class non-based on Object,
  • "ctorO_InnerClassName" for a non-static constructor of a inner class based on Object. In this case the constructor is searched first in the given ClassData of the inner class, but it isn't found there. Because the inner-class has an outer one, the searching is continued in the outer class, and there the constructor is found as a non-static one.
  • "ctorM_InnerClassName" adequate non-Object-based.

  To difference whether or not the associated class is a non-static-inner one, the property ClassData.isNonStaticInner is checked. This rules are regarded in

  • StatementBlock#genInitEmbeddedInstance(org.vishia.zbnf.ZbnfParseResultItem, org.vishia.zbnf.ZbnfParseResultItem, FieldData, String, int)
  • StatementBlock#gen_newObject(org.vishia.zbnf.ZbnfParseResultItem, CCodeData, LocalIdents)

  The correct constructor is found depending on its parameter, which are given as second param while calling ClassData#searchMethod(String, java.util.List, boolean).

• f9_intension_of_call

  public void f9_intension_of_call()

  The translation process of details should know informations about its environment of call. At example it is a difference whether a expression is evaluated for an assignment or to provide an actual parameter. Therefore a parameter named 'intension' is used often.

  • 'C' Class level variable def or inner class
  • 'c' constructor body,
  • 'm' gen_statementBlock: -method body,
  • 'b' internal block,
  • 'z' part of if, while etc.,
  • 'f' finalize body.
  • '=' . The argument retIdentInfo is a call by returned reference.
  • 'R' the left element of a reference.
  • 'r' for the next nested reference
  • 'e' gen_value:-value in an expression, enhanced references are taken with .ref
  • 'l' gen_value:-left value,
  • 'a' gen_value:-argument in c-file (head of routine)
  • 'A' gen_value:-argument in h-file (prototype-definition)
  • 't' gen_simpleMethodCall: String concatenation
  • 'i' gen_assignValue: init value
  • 's' Static variable
  • 'P' top-level class
  • 'Y' anonymous inner class at class level
  • 'x' extern
  • 'u' throw text expression, use String Buffer in Thread context.

  Usage in several methods:

  	Ccmbzf=RrelaAtisPYxu	method
  --------------------	SecondPass#gen_statementBlock(org.vishia.zbnf.ZbnfParseResultItem, int, org.vishia.java2C.StatementBlock, FieldData, char)
  -cmb-f-----aA-------	SecondPass#gen_variableDefinition(org.vishia.zbnf.ZbnfParseResultItem, org.vishia.zbnf.ZbnfParseResultItem, LocalIdents, java.util.List, char)
  C--------------s----	GenerateClass#gen_AnonymousClass(org.vishia.zbnf.ZbnfParseResultItem, LocalIdents, String, char, GenerateFile)
  Ccmb------------P---	FirstPass#buildType(StringBuilder, String, GenerateFile, String, String, String, String, org.vishia.zbnf.ZbnfParseResultItem, boolean, String, ClassData, java.util.List, boolean, ClassData, char)
  Ccmb------------PYx-	ClassData#ClassData(String, GenerateFile, String, String, String, String, String, char, ClassData, ClassData, ClassData[], org.vishia.zbnf.ZbnfParseResultItem, String, char, LocalIdents)
  ---------ela-------u	StatementBlock#gen_simpleValue(org.vishia.zbnf.ZbnfParseResultItem, org.vishia.zbnf.ZbnfParseResultItem, org.vishia.zbnf.ZbnfParseResultItem, LocalIdents, boolean, char, boolean)