Texas Instruments TMS320 DSP manual Naming Conventions, Module Initialization and Finalization

www.ti.com

Interfaces and Modules

3.1.2 Naming Conventions

To simplify the way eXpressDSP-compliant client Code is written, it is valuable to maintain a single consistent naming convention. In addition to being properly prefixed (Rule 8), all external declarations disclosed to the user must conform to the eXpressDSP naming conventions.

Rule 10

All modules must follow the eXpressDSP-compliant naming conventions for those external declarations disclosed to the client.

Note that the naming conventions only apply to external identifiers. Internal names and existing Code need not change unless an identifier is externally visible to a client application. The eXpressDSP naming conventions are summarized in the table below.

Convention

Variables and functions

Constants

Types

Structure fields

macros

Description

Variables and functions begin with lowercase (after the prefix).

Constants are all uppercase

Data types are in title case (after the prefix)

Structure fields begin with lowercase

Macros follow the conventions of constants or functions as appropriate

Example

FIR_apply()

G729_FRAMELEN

FIR_Handle

buffer

FIR_create()

In addition to these conventions, it is important that multi-word identifiers never use the '_character' to separate the words. To improve readability use title case; for example, FIR_getBuffer() should be used in lieu of FIR_get_buffer(). This avoids ambiguity when parsing module and vendor prefixes.

3.1.3 Module Initialization and Finalization

Before a module can be used by an application, it must first be "initialized"; i.e., the module'sinit() method must be run. Similarly, when an application terminates, any module that was initialized must be "finalized," i.e., its exit() method must be executed. Initialization methods are often used to initialize global data used by the module that, due to limitations of the C language, cannot be statically initialized. Finalization methods are often used to perform run-time debug assertions; for example, it might check for objects that were created but never deleted. The finalization method of a non-debug version of a module is often the empty function.

Although some modules have no need for initialization or finalization, it is easier for the clients of modules to assume that all modules have them. This allows frameworks to easily implement well-defined startup and shutdown sequences, for example.

Rule 11

All modules must supply an initialization and finalization method.

3.1.4 Module Instance Objects

Modules optionally manage instance objects. All eXpressDSP-compliant modules manage instance objects. Objects simply encapsulate the persistent state that is manipulated by the other functions or methods provided by the module.

A module manages only one type of object. Thus, a module that manages objects roughly corresponds to a C++ class that follows a standard naming convention for its configuration parameters, interface header, and all external identifiers as shown in Figure 3-2.

28 Algorithm Component Model SPRU352G –June 2005 –Revised February 2007

Submit Documentation Feedback