The general form of the class definition for BER, DER, or PER encoding rules is as follows:

   class ASN1C_<name> : public ASN1CType {
     protected:
        ASN1T_<name>& msgData;
     public:
        ASN1C_<name> (ASN1T_<name>& data);
        ASN1C_<name> (
           ASN1MessageBufferIF& msgBuf, ASN1T_<name>& data);

        // standard encode/decode methods (defined in ASN1CType base class):
        // int Encode ();
        // int Decode ();

        // stream encode/decode methods:
        int EncodeTo (ASN1MessageBufferIF& msgBuf);
        int DecodeFrom (ASN1MessageBufferIF& msgBuf);
   } ;

The name of the generated class is ASN1C_<name> where <name> is the name of the production. The only defined attribute is a protected variable reference named msgData of the generated type.

Two constructors are generated. The first is for stream operations and allows the control class to be created using only a reference to a variable of the generated type.

The EncodeTo and DecodeFrom methods can then be used to encode or decode directly to and from a stream. The << and >> stream operators can be used as well.

The second constructor is the legacy form that allows a message buffer to be associated with a data variable at the time of creation. The Encode and Decode methods defined in the ASN1CType base class can be used with this construction form to encode and decode to the associated buffer.

The constructor arguments are a reference to an ASN1MessageBufferIF (message buffer interface) type and a reference to an ASN1T_<name> type. The message buffer interface argument is a reference to an abstract message buffer or stream class. Implementations of the interface class are available for BER/DER, PER, or XER encode or decode message buffers or for a BER or XER encode or decode stream.

The ASN1T_<name> argument is used to specify the data variable containing data to be encoded or to receive data on a decode call. The procedure for encoding is to declare a variable of this type, populate it with data, and then instantiate the ASN1C_<name> object to associate a message buffer object with the data to be encoded. The Encode or Encode To method can then be called to encode the data. On the decode side, a variable must be declared and passed to the constructor to receive the decoded data.

Note that the ASN1C_ class declarations are only required in the application code as an entry point for encoding or decoding a top-level message (or Protocol Data Unit – PDU). As of ASN1C version 5.6, control classes are only generated for ASN.1 types that are determined to be PDU’s. A type is determined to be a PDU if it is referenced by no other types. This differs from previous versions of ASN1C where control classes were generated for all types. This default behavior can be overridden by using a configuration file entry or the -pdu command-line switch to explicitly declare the PDU types. The <isPDU/> flag is used to declare a type to be a PDU in a configuration file. An example of this is as follows:

   <asn1config>
      <module>
         <name>H323-MESSAGES</name>
         <production>
            <name>H323-UserInformation</name>
            <isPDU/>
         </production>
      </module>
   </asn1config>

This will cause only a single ASN1C_ control class definition to be added to the generated code for the H323- UserInformation production.

If the module contains no PDUs (i.e,. contains support types only), the <noPDU/> empty element can be specified at the module level to indicate that no control classes should be generated for the module.