When the –tables command line option is used, additional code is generated to support the additional processing required to verify table constraints. This code varies depending on whether C or C++ code generation is selected. The C++ code is designed to take advantage of the object-oriented capabilities of C++. These capabilities are well suited for modeling the behavior of information objects in practice. The following subsections describe the code generated for each of these languages.
The code generated to support these constraints 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.
For C, code is generated for the Information Object Sets defined within a specification in the form of a global array of structures. Each structure in the array is an equivalent C structure representing the corresponding ASN.1 information object.
Additional encode and decode functions are also generated for each type that contains table constraints. These functions have the following prototypes :
BER/DER
int asn1ETC_<ProdName> (OSCTXT* pctxt, <ProdName>* pvalue); int asn1DTC_<ProdName> (OSCTXT* pctxt, <ProdName>* pvalue);
PER
int asn1PETC_<ProdName> (OSCTXT* pctxt, <ProdName>* pvalue); int asn1PDTC_<ProdName> (OSCTXT* pctxt, <ProdName>* pvalue);
The purpose of these functions is to verify the fixed values within the table constraints are what they should be and to encode or decode the open type fields using the encoder or decoder assigned to the given table row. Calls to these functions are automatically built into the standard encode or decode functions for the given type. They should be considered hidden functions not for use within an application that uses the API.
For C++, code is generated for ASN.1 classes, information objects, and information object sets. This code is then referenced when table constraint processing must be performed.
Each of the generated C++ classes builds on each other. First, the classes generated that correspond to ASN.1 CLASS definitions form the base class foundation. Then C++ classes derived from these base classes corresponding to the information objects are generated. Finally, C++ singleton classes corresponding to the information object sets are generated. Each of these classes provides a container for a collection of C++ objects that make up the object set.
Additional encode and decode functions are also generated as they were in the C code generation case for interfacing with the object definitions above. These functions have the following prototypes:
BER/DER
int asn1ETC_<ProdName> (OSCTXT* pctxt,
<ProdName>* pvalue,
<ClassName>* pobject);
int asn1DTC_<ProdName> (OSCTXT* pctxt,
<ProdName>* pvalue,
<ClassName>* pobject);
PER
int asn1PETC_<ProdName> (OSCTXT* pctxt,
<ProdName>* pvalue,
<ClassName>* pobject);
int asn1PDTC_<ProdName> (OSCTXT* pctxt,
<ProdName>* pvalue,
<ClassName>* pobject);
These prototypes are identical to the prototypes generated in C code generation case except for the addition of the pobject argument. This argument is for a pointer to the information object that matches the key field value for a given encoding. These functions have different logic for processing Relative and Simple table constraints. The logic associated with each case is as follows:
On the encode side:
Relative Table Constraint:
The lookupObject method is invoked on the object set instance to find the class object for the data in the populated type variable to be encoded.
If a match is found, the table constraint encode function as defined above is invoked. This function will verify all fixed type values match what is defined in the information object definition and will encode all type fields and store the resulting encoded data in the ASN1TObject.encoded fields.
If a match is not found and the information object set is not extensible, then a table constraint error status will be returned. If the information object set is extensible, a normal status is returned.
Simple Table Constraint:
This function will verify all the fixed type values match what is defined in the table constraint information object set. If an element value does not exist in the table (i.e. the information object set) and the object set is not extensible, then a table constraint violation exception will be thrown.
The normal encode logic is then performed to encode all of the standard and open type fields in the message.
On the decode side, the logic is reversed:
The normal decode logic is performed to populate the standard and open type fields in the generated structure.
Relative Table Constraint:
The lookupObject method is invoked on the decoded key field value to find an object match.
If a match is found, the table constraint decode function as defined above is invoked. This function will verify all fixed type values match what is defined in the information object definition and will fully decode all type fields and store pointers to the decoded type variables in the ASN1TObject.decoded fields.
If a match is not found and the information object set is not extensible, then a table constraint error status will be returned. If the information object set is extensible, a normal status is returned.
Simple Table Constraint:
This function will verify all the fixed type values match what is defined in the table constraint object set. If an element value does not exist in the table (i.e. the information object set) and the object set is not extensible, then a table constraint violation exception will be thrown.