CLASS specification

---

NOTE: Class code generation is available for -tables option only.   This additional code is generated to support the processing required to verify table constraints. This is intended for use only in compiler-generated code. Therefore, it is not necessary for the average user to understand the mappings in order to use the product. The information presented here is informative only to provide a better understanding of how the compiler handles table constraints.

All of the Class code will be generated in a module class header file with the following filename format:

<ModuleName>Class.h

In this definition, <ModuleName> would be replaced with the name of the ASN.1 module name for this class definition.

C Code generation:

The C struct definition generated to model an ASN.1 class contains member variables for each of the fields within the class.

For each of the following class fields, the corresponding member variable is included in the generated C structure as follows:

For a Value Field:

  <TypeName> <FieldName>;
 

 

For TypeField definitions, an encode and decode function pointer and type size field is generated to hold the information of the type for the OpenType. If the -print option is selected, a print function pointer is also added.

   int <FieldName>Size;
 
   int (*encode<FieldName>) (... );
 
   int (*decode<FieldName>) (... );
 
   void (*print<FieldName>) (...);
 

 

For an Object Field:

   <ClassName>* <FieldName>;
 

 

For an ObjectSetField definition, an array of class definitions is generated to hold the list of information objects.

   <ClassName>* <FieldName>;
 

 

In each of these definitions:

<FieldName> would be replaced with the name of the field (without the leading `&').

<TypeName> would be replaced with the C type name for the ASN.1 Type.

<ClassName> would be replaced with the C type name of the class for the Information Object.

As an example, consider the following ASN.1 class definition :

ATTRIBUTE               ::=     CLASS {
 
        &Type,
 
        &id                     OBJECT IDENTIFIER UNIQUE }
 
WITH SYNTAX {
 
        WITH SYNTAX &Type ID &id }
 

This would result in the following definition in the C source file:

typedef struct ATTRIBUTE {
 
   int TypeSize;
 
   int (*encodeType) (ASN1CTXT* , void *, ASN1TagType );
 
   int (*decodeType) (ASN1CTXT* , void *, ASN1TagType, int );
 

ASN1OBJID id;

}

C++ Code generation:

The C++ abstract class generated to model an ASN.1 CLASS contains member variables for each of the fields within the class. Derived information object classes are required to populate these variables with the values defined in the ASN.1 information object specification. The C++ class also contains virtual methods representing each of the type fields within the ASN.1 class specification. If the field is not defined to be OPTIONAL in the ASN.1 specification, then it is declared to be abstract in the generated class definition. A class generated for an ASN.1 information object that references this base class is required to implement these abstract virtual methods.

For each of the following CLASS fields, a corresponding member variable is generated in the C++ class definition as follows:

For a Value Field definition, the following member variable will be added. Also, an Equals() method will be added if required for table constraint processing.

   <TypeName> <FieldName>;
 

 
   inline OSBOOL idEquals  (<TypeName>* pvalue)
 

For a Type Field definition, a virtual method is added for each encoding rules type to call the generated C encode and decode functions. If -print is specified, a print method is also generated.

   virtual int encode<ER><FieldName>
 
      (ASN1CTXT* pctxt, ASN1TObject& object) { return 0; }
 

 
   virtual int decode<ER><FieldName>
 
      (ASN1CTXT* pctxt, ASN1TObject& object) { return 0; }
 

 
   virtual void print<FieldName>
 
      (ASN1ConstCharPtr name, ASN1TObject& object) {}
 

For an Object Field:

   class <ClassName>* <FieldName>;
 

 

In each of these definitions:

<FieldName> would be replaced with the name of the field (without the leading `&').

<TypeName> would be replaced with the C type name for the ASN.1 Type.

<ClassName> would be replaced with the C type name of the class for the Information Object.

<ER> would be replaced by an encoding rules type (BER, PER, or XER).

As an example, consider the following ASN.1 class definition :

ATTRIBUTE ::= CLASS {
 
        &Type,
 
        &ParameterType OPTIONAL,
 
        &id            OBJECT IDENTIFIER UNIQUE }
 
WITH SYNTAX {
 
        WITH SYNTAX &Type ID &id }
 

This would result in the following definition in the C++ source file:

class EXTERN ATTRIBUTE {
 
 protected:
 
   ASN1TObjId id;
 

 
   ATTRIBUTE ();
 

 
 public:
 
   virtual int encodeBERType
 
      (ASN1CTXT* pctxt, ASN1TObject& object) = 0;
 

 
   virtual int decodeBERType
 
      (ASN1CTXT* pctxt, ASN1TObject& object) = 0;
 

 
   OSBOOL isParameterTypePresent() {
 
       if(m.ParameterTypePresent) {return TRUE;} else {return FALSE;}
 
   }
 
   virtual int encodeBERParameterType
 
      (ASN1CTXT* pctxt, ASN1TObject& object) { return 0; }
 

 
   virtual int decodeBERParameterType
 
      (ASN1CTXT* pctxt, ASN1TObject& object) { return 0; }
 

 
   inline OSBOOL idEquals (ASN1TObjId* pvalue)
 
   {
 
      return (0 == rtCmpTCOID (&id, pvalue));
 
   }
 
} ;
 

 

This assumes that only BER or DER was specified as the encoding rules type.

First notice that member variables have been generated for the fixed-type fields in the definition. These include the id field. Information object classes derived from this definition are expected to populate these fields in their constructors.

Also, virtual methods have been generated for each of the type fields in the class. These include the Type fields. The method generated for Type is abstract and must be implemented in a derived information object class. The method generated for the ParameterType field has a default implementations that does nothing. That is because it is a optional field.

Also generated are Equals methods for the fixed-type fields. These are used by the generated code to verify that data in a generated structure to be encoded (or data that has just been decoded) matches the table constraint values. This method will be generated only if it is required to check a table constraint.

OPTIONAL keyword:

Fields within a CLASS can be declared to be optional using the OPTIONAL keyword. This indicates that the field is not required in the information object. An additional construct is added to the generated code to indicate whether an optional field is present in the information object or not. This construct is a bit structure placed at the beginning of the generated structure. This structure always has variable name `m' and contains single-bit elements of the form <field-name>Present as follows:

	struct {
 
	   unsigned <field-name1>Present : 1,
 
	   unsigned <field-name2>Present : 1,
 
	   ...
 
	} m;
 

In this case, the fields included in this construct correspond to only those fields marked as OPTIONAL within the CLASS. If a CLASS contains no optional fields, the entire construct is omitted.

For example, we will change the CLASS in the previous example to make one field optional:

 
    ATTRIBUTE ::= CLASS {
 
        &Type OPTIONAL,
 
        &id   OBJECT IDENTIFIER UNIQUE 
 
    }
 

In this case, the following C typedef is generated in C struct or C++ class definition:

    struct {
 
        unsigned TypePresent : 1;
 
    } m;
 

When this structure is populated for encoding, the information object processing code will set TypePresent flag accordingly to indicate whether the field is present or not.

In C++ code generation, an additional method is generated for an optional field as follows:

 
   OSBOOL is<FieldName>Present() {
 
       if (m.<FieldName>Present) {return TRUE;} else {return FALSE;}
 
   }
 

This function is used to check if the field value is present in an information object definition.

Generation of New ASN.1 Assignments from CLASS Assignments:

During CLASS definition code generation, the following new assignments are created for C or C++ code generation:

1. A new Type Assignment is created for a TypeField's type definition, as follows:

    _<ClassName>_<FieldName>    ::=    <Type>
 

 

Here ClassName is replaced with name of the Class Assignment and FieldName is replaced with name of this field. Type is the type definition in CLASS's TypeField.

This type is used as a defined type in the information object definition for an absent value of the TypeField. It is also useful for generation of a value for a related Open Type definition in a table constraint.

2. A new Type Assignment is created for a Value Field or Value Set Field type definition as follows (if the type definition is one of the following: ConstraintedType / ENUMERATED / NamedList BIT STRING / SEQUENCE / SET / CHOICE / SEQUENCE OF / SET OF ):

    _<ClassName>_<FieldName>    ::=    <Type>
 

 

Here ClassName is replaced with the name of the CLASS assignment and FieldName is replaced with name of the ValueField or ValueSetField. Type is the type definition in the CLASS's ValueField or ValueSetField. This type will appear as a defined type in the CLASS's ValueField or ValueSetField.

This new type assignment is used for compiler internal code generation purpose. It is not required for a user to understand this logic.

3. A new Value Assignment is created for a ValueField's default value definition as follows:

    _<ClassName>_<FieldName>_default   <Type>  ::=   <Value>
 

 

Here ClassName is replaced with name of the Class Assignment and FieldName is replaced with name of this ValueField. Value is the default value in Class's ValueField and Type is the type in Class's ValueField.

This value is used as a defined value in the information object definition for an absent value of the field. This new value assignment is used for compiler internal code generation purpose. It is not required for user to understand this logic.