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
.log
OUTLOG(level, ) // 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