CLIP home page

#### Extensions in compiler and preprocessor

All words beginning with HASH_ are translated by the preprocessor into hashstr("HASH_....."). We need this to reduce the number of files included. And, instead of writing

            #define HASH_asdf   12345678
            #define HASH_qwerty 231423534

and so on, we may simply use HASH_.... key words in the program text, e.g.

            do case
            	case HASH_asdf
                    case HASH_qwerty
                    ....
            endcase

You may be sure that, if you come accross a set of HASH_asdf symbols in different prg files, the result will be identical, as if the word had been announced via #define.

The preprocessor can get data from the environment, for instance:

            #define $USER

will be actually translated into

            #define uri

In particular, you may use CLIP_LANG environment variable to change the language spoken by clip libraries. For example:

            export CLIP_LANG=LANG_RUSSIAN

there are some predefined constants:

    	__FILE__
    	__BASE_FILE__
    	__LINE__
    	__VERSION__
    	__CLIP__
    	__SYSTEM__
    	__DATE__
    	__TIME__

New preprocessor command is added - #xdefine - being the same as #define, but insensible to the case of macros name announced.

The set of options may be written into .cliprc file, and the latter may be put into the home or current directory.

In addition to std.ch, some more automatically included head files may be written by putting in .cliprc file strings like:

     -U std.ch
     -U clip.ch
     -U config.ch

Compiler options are not in full compliance with the standard Clipper compiler, error and warning messages being not in compliance at all. But we believe that this incompliance will not give you great troubles.

The compiler can decode source codes in various Russian codes during the compilation, i.e. you may write programs in DOS and, without tricks, make them in UNIX. The only restriction: file names must be in the lower case.

##### The compiler can generate

- po files - pseudocode or extended code block - small size, fast compilation, possible downloading in run-time, slow execution. These po-files are easily decompiled, but there is no decompiler itself yet.
- C-programs - size 2 to 3 times larger than that of PO, compiled from C sources into object modules for a long time, operation 30 to 50% faster than that of PO, easily managed by tools of C-developer, decompilation is impossible. But, as for size and execution speed, manual coding is still more efficient; therefore, if you need fast functions, write them in C, or you may contact us, and we'll write them in C.
- C+PO programs - pseudocode inside C program - quickly compilated, small size, slow operation, but managed by standard tools of C developer. Theoretically, decompilation is possible, though this is much more complex than for PO files.
- Programs using dynamically loaded libraries (-s options). For information, please read about clip_run, and you'll get clear understanding how to do this.

Libraries are made of O files by standard librarians.

Libraries are made of PO files by clipar utility.

GET command has been changed, formerly it called _GET_ internal function, and now it calls GETNEW with added parameters.

Now, in run-time, you may download a pseudocode (code blocks) from files; For example, mylib.prg is being done, in which

       func myfunc1
       return 1
       func myfunc2
       return 2

command is being done

       clip -p mylib.prg,

as a result, mylib.po file with a pseudocode inside appears.
During the operation of any program, you may write:

       load("mylib.po")
       ? myfunc1()
       ? myfunc2()

In addition to outdev and outerr, one more output stream into log file was made.

        SET(_SET_LOGLEVEL,num_level) // sets debug level
        SET(_SET_LOGFILE,filename)   // sets log file name; if it isn't set,
                                        the whole output will be directed into
                                        <program_name>.log
        OUTLOG(level, <list ,,,>)    // if the level isn't indicated, or the
        				    first indicated parameter isnt't a number,
        				    this information will ALWAYS be output
        				    into log file irrespective of current
                                        debug level.

For applied logging, use levels 1 to 3; level 4 gives information on called functions compiled as a byte code; level 5 outputs information on all functions called.
Note - log file isn't removed, therefere you need to do this yourselves.

As an explanation and recommendation: we would use

- level 0 - who and when run program, errorsys, call of important operations like indexing.
- level 1 - what menu items were called, what large modules of a program were used
- level 3 - analysis of time critical procedures, analysis of user activities and the like, document printing, access to "secret" data and so on.

CLIP home page

© Uri Khnykin, uri@itk.ru, 2000