KlemC Reference Manual(preliminary)

Table of Contents

KlemC Purpose

The Way KlemC Works

DOCS

@

DOCROUTINE

DOCOBJECT

DOCLIST

DOCTYPEDEF

DOCDEFINE

CODE DIRECTIVES

PREDEFINED

INCLUDE

INCLUDES

TYPEDEFS

DEFINES

VARIABLES

ROUTINES

OBJECT

EXECUTE

DEBUGGING

DEBUG

DEBUGLIST

QUESTIONS OR PROBLEMS?

 

KlemC Purpose

The purpose of KlemC is to provide an easier way to develop C/C++ programs. C and C++ provide very efficient, very highly optimized code, but is not the easiest language to work with. KlemC provides the following things:

No prototypes are needed.

Order dependencies are minimized.

Elimination of many of the syntax requirements.

Semicolon';' not required at the end of most instructions.

Parenthesis'()' is not required around if equations.

Brackets '{}' are not needed..

Standardized error handling.

Standardized debugging.

Debug shows how the code got to the bad spot.

History of previous failures is available. The date and time of each failure is present.

Multiple failures that are the same will be noted in the debug file.

Better modularization of code.

Documentation can be included with the code.

Man style documentation.

Documentation can be changed whenever the code changes.

Compilation string is in the code. No research has to be done to compile the package.

Any shell like execution, can automatically be run.

Handling of multiple objects.

Automatic pointers to objects variables and routines. As long as the object variables and routines are unique names, the software will provide a pointer to the object variable or routine.

Allow object routines to be organized in separate files. An object does not have to be defined together.

The Way KlemC Works

KlemC is a file with commands combined with C/C++ code and/or documentation. The KlemC program will process the inputs. KlemC will build the C/C++, and if the build is successful, it will do the commands in the execute section. The execute section can have the C/C++ compile commands as well as any commands that might be used to test the build.

A KlemC program is divided into sections. Each section command must be at

 the beginning of a line.

KlemC section

Options

Purpose

INCLUDES

 

Contains '#include' statements.

TYPEDEFS

proto/noProto

Contains '#define' and '#typedef' statements. These statements should not have any dependencies on other statements.

DEFINES

proto/noProto

Contains  '#define' statements that may have dependencies on  previous '#define' and '#typedef' statements.

VARIABLES

proto/noProto

globals/threads

Contains global variables.

ROUTINES

proto/noProto

Contains routines that are not attached to an object.

OBJECT objectName

proto/noProto

routines/variables

“pointer”

Contains object routines or variables.

EXECUTE

 

This contains the shell commands needed to compile the generated code. It may also contain commands to install and or test the code.

DOCS

 

This contains man style documentation.

  1. proto/noProto optional keywords. Care must be taken when using this with order dependencies.

proto = The prototypes and inline code for this section will be placed in a programName.h file.

noProto(default) = The prototypes and inline code for this section will be placed at the beginning of the programName.cc file.

globals/threads keywords

globals = The variables specified in this section will be global for all threads.

threads = The variables specified in this section will have a unique copy for each thread.

routines/variables keywords

routines = This section will contain routines that belong to the object.

variables = This section contains variables that belong to the object.

“pointer” optional string -  If one of the objects routines or variables is used without a prefix, and is located outside of the objects section, this pointer string will automatically be inserted in front of the name. This option will only work if the name used is unique.

KlemC works with the Klemlib libraries. These provide standard general purpose routines, and standard error handling as well as debugging. The library has some abbreviated variable types:

KlemC type

C type

char

char

uchar

unsigned char

short

short

ushort

unsigned short

int

int

uint

unsigned int

long

long int

ulong

unsigned long int

llong

long long int

ullong

unsigned long long int

float

float

double

double

string

char

cstring

const char

DOCS

Syntax:

DOCS

@category.subject – Short description

man page contents

…

@category.nextSubject – Short description

other contents

…

Description:

This section is to create man style documentation. The cman routine will display the documentation.

Each entry is layered by category, and then the subject.

@

Syntax:

@category.subject – Short description

Description:

This symbol is used to separate each new documentation subject. Each subject uses a period(.) to separate the categories which will be used to find the subject.

DOCROUTINE

Syntax:

 DOCROUTINE [objectName] "searchPhrase"

Inputs:

objectName - This is an optional object name. If this name is specified, only routines belonging to the specified object will be listed.

“SearchPhrase” – All routines that contain this phrase will be listed. If this string is blank(“”), and an object is specified, all routines for the object will be listed.

Description:

This keyword will list all routine prototypes for the routines that exist in the source code.

DOCOBJECT

Syntax:

DOCOBJECT objectName

Inputs:

objectName – The object name.

Description:

This keyword will list all the variables that belong to the given object.

DOCLIST

Syntax:

DOCLIST “searchPhrase”

Inputs:

“searchPhrase” – List all descriptions that start with this phrase.

Description:

This keyword will search all the man page headers for searchPhrase. It will the header line for each man subject found.

DOCTYPEDEF

Syntax:

DOCTYPEDEF “searchPhrase”

Inputs:

“searchPhrase” – List all typedefs that start with this phrase.

Description:

This keyword will list all statements in the TYPEDEF sections that  start with searchPhrase.

DOCDEFINE

Syntax:

DOCDEFINE “searchPhrase”

Inputs:

“searchPhrase” – List all typedefs that start with this phrase.

Description:

This keyword will list all statements in the DEFINE sections that  start with searchPhrase.

CODE DIRECTIVES

This keyword will list all the document descriptions that have the given search phrase.

PREDEFINED

Syntax:

PREDEFINED name name …

Inputs:

name – The name of the #typedef variable.

Description:

This keyword is used to tell KlemC of type defined variable types. This is used for libraries and modules that KlemC does not know about.

INCLUDE

Syntax:

INCLUDE “fileName”

Inputs:

fileName – The KlemC file to include

Description:

This keyword is used to tell KlemC to also use the given file.

INCLUDES

Syntax:

INCLUDES

#include “filename”

…

Description:

This section is for any C include statements. These statements will be put in the beginning of the program, regardless of where they are located in the KlemC source.

TYPEDEFS

Syntax:

TYPEDEFS [noProto/proto]

#define …

…

Options:

noProto – This is the default. Do not put the code in this section in the main(xxx.cc) file.

Proto – Put the code in this section in the header(xxx.h) file.

Description:

This section is for code that will be first in the generated C code. The statements in this section should not be dependent on previous statements.

DEFINES

Syntax:

DEFINES [noProto/proto]

#define …

…

Options:

noProto – This is the default. Do not put the code in this section in the main(xxx.cc) file.

Proto – Put the code in this section in the header(xxx.h) file.

Description:

This section is for code that will be located after all code in the TYPEDEFS section. Code in this section should only depend on previous code.

VARIABLES

Syntax:

VARIABLES globals/threads [noProto/proto]

int var1

string var2[128] =

't','e',

's','t'

Options:

globals – These variables will be global for all threads.

threads – These variables are global for each separate thread.

noProto – This is the default. Do not put the code in this section in the main(xxx.cc) file.

Proto – Put the code in this section in the header(xxx.h) file.

Description:

This section is for global variables. This section is formatted, which means semicolons(;) will be added where they are needed. If and for statements will have parenthesis added. And any indented code will be encased in brackets({}).

Example:

VARIABLES threads

int var1

string var2[128] =

't','e',

's','t'

ROUTINES

Syntax:

ROUTINES [noProto/proto]

Options:

noProto – This is the default. Do not put the code in this section in the main(xxx.cc) file.

Proto – Put the code in this section in the header(xxx.h) file.

Description:

This section is for general routines that are not attached to an object.

Example:

ROUTINES

int inccIt(int a=0)

return(++a)

 

OBJECT

Syntax:

OBJECT name variables/routines [proto/noProto] [“pointer”]

Options:

variables – The code in this section is the variables used in the object.

threads – The code in this section is routines owned by the object.

noProto – This is the default. Do not put the code in this section in the main(xxx.cc) file.

proto – Put the code in this section in the header(xxx.h) file.

“pointer” - Code that will be used to point to an object routine or variable when an object routine or

 variable name is encountered.

Description:

This section is for object definitions. This section is formatted, which means all statements will be followed by a semicolon(;). And any indented code will be encased in brackets({}).

Example:

OBJECT varObj variables  â€œvarObjPtr->”

int varObjA

cstring *varObjName

OBJECT varObj routines

void varObjSet(int a, cstring *name)

varObjA = a

varObjName = name

VARIABLES

varObj * = varObjPtr

ROUTINES

void initAll()

varObjPtr = new varObj

varObjSet(0,””)

EXECUTE

Syntax:

EXECUTE

Description:

This section is used to tell KlemC what to do after successfully generating the C code.

Example:

$COMPILE test.cc -o test

./test

DEBUGGING

The goal of the KlemC debug system is to be able to debug non reproducible failures remotely.  It accomplishes this by recording a dump file of debug history in the $KHOME/debug directory. The modtime date on the files will tell when the debug file was dumped.

DEBUG

Syntax:

DEBUG type printfPhrase printfVars …

Options:

type – This is the debug class. This phrase can be used to enable/disable debug statements. This can be a predefined phase or a number. The following are the predefined phrases:

debugGeneral

0x1

General debug statement.

debugDetail

0x2

Detail debug statement.

debugMoreDetail

0x4

More details.

debugRoutines

0x10

General routine statement.

debugRoutinesEnd

0x20

End of a general routine statement.

debugBase

0x100

Base debug statement.

debugBaseEnd

0x200

Base end statement.

printfPhrase – This is a printf format phase that makes up the debug statement. It supports the standard printf % options. The exception is a %s is followed by a number that is the number of 8 character groups used.

PrintfVars – The variables specified by ege printfPhrase.

Description:

This statement should be sprinkled throughout the code. Pointers to the statements and the variables will be saved at execute time. On and error(an errorEnd call, or an error signal), the statements will be built and dumped to the disk.

DEBUGLIST

Syntax:

DEBUGLIST object “destPtr”

Options:

object – The object name to debug.

destPtr – A pointer to the string buffer that will contain the dump of the object.

Description:

This command will dump the values of all the variables in the given object.

QUESTIONS OR PROBLEMS?

 Contact Dave Klemer (davidKlemer@yahoo.com)