Все слова начинающиеся на HASH_, препроцессор переводит в
hashstr("HASH_....."). Нам это нужно, для того чтобы уменьшить
количество включаемых (#include) файлов. И вместо того чтобы писать
#define HASH_asdf 12345678
#define HASH_qwerty 231423534
и т.п., теперь можно просто в тексте программы
использовать ключевые слова HASH_...., например:
do case
case HASH_asdf
case HASH_qwerty
....
endcase
И, при этом, можно быть уверенным, что если в разных prg-файлах попадется
набор символов HASH_asdf, то результат будет одинаков, как если бы это
слово было бы объявлено через #define.
Препроцессор умеет доставать данные из окружения, например:
#define $USER
будет фактически странслировано в
#define uri
В частности, можно использовать переменную окружения CLIP_LANG для
изменения языка, на котором говорят clip-библиотеки. Например:
export CLIP_LANG=LANG_RUSSIAN
имеются предопределенные препроцессором #define:
__FILE__
__BASE_FILE__
__LINE__
__VERSION__
__CLIP__
__SYSTEM__
__DATE__
__TIME__
Появилась команда препроцессора #xdefine - это то же самое, что и
#define, но не чувствительна к регистру объявляемого имени макроса.
Конфигурацию ключиков можно прописать в файл .cliprc, и положить этот
файл в домашний или текущий каталог.
В дополнение к std.ch можно прописать еще несколько автоматически
подключаемых заголовочных файлов, прописав в .cliprc-файле строчки типа:
-U std.ch
-U clip.ch
-U config.ch
Ключики компилятора не совсем соответствуют стандартному Клиппер-компилятору.
Формулировки ошибок и предупреждений компилятора совсем не соответствуют.
Но я не думаю, что это несоответсвие доставит большие неприятности.
Компилятор умеет перекодировать исходные тексты в разные русские кодировки
во время компиляции. Т.е. вы можете писать программы в DOS, и без всяких
ухищрений собирать программы в UNIX.
Единственное ограничение - имена файлов должны быть в нижнем регистре.
Компилятор умеет генерировать
PO-файлы - псевдокод или продвинутые кодовые блоки - небольшой размер,
быстрая компиляция, возможность загружать в run-time, медленное выполнение.
Легко декомпилируются, но самого декомпилятора пока нет.
С-программы - размер в 2-3 раза больше чем у PO, долго компилируются
из С в объектные модули, работают на 30-50% быстрее чем PO, легко
управляются штатными средствами С-разработчика, не подлежат декомпиляции.
Но все-таки ручное кодирование более эффективно, как по размеру, так и по
скорости выполнения. Так что если вам нужны быстродействующие функции -
пишите их на С, или напишите нам что вам нужно, а мы напишем на С.
C+PO-программы - псевдокод обернутый в С-программу - быстро
компилируются. Имеют маленький размер, медленно работают, но зато
управляются стандартными средствами С-разработчика.
Декомпиляция теоретически возможна, но намного сложнее чем
декомпиляция PO-файлов.
Программы с использованием динамически загружаемых библиотек (-s).
Для примера почитайте о clip_run.
O-файлы собираются в библиотеки стандартными библиотекарями.
PO-файлы собираются в библиотеки утилитой clipar.
Изменена формулировка команды GET, раньше она вызывала встроенную
функцию _GET_, а теперь GETNEW с добавленными параметрами.
Теперь можно в run-time загружать псевдокод (кодовые блоки) из файлов,
например делается файл mylib.prg, в котором
func myfunc1
return 1
func myfunc2
return 2
делается команда
clip -p mylib.prg,
в результате рождается файл mylib.po с псевдокодом внутри.
А во время работы любой программы можно написать:
load("mylib.po")
? myfunc1()
? myfunc2()
В довесок к outdev, outerr сделан еще один поток вывода информации -
в log-файл.
SET(_SET_LOGLEVEL,num_level) // задает уровень отладки
SET(_SET_LOGFILE,filename) // задает имя log-файла, если не задано,
то весь вывод будет направлен в
<имя_программы>.log
OUTLOG(level, ) // если level не указан или
первым параметром указано не число,
то данная информация будет выводиться
в log-файл ВСЕГДА не зависимо от
текущего уровня отладки.
Для прикладного логгирования используйте уровни 1-3, 4 уровень дает
информацию о вызываемых функциях, скомпилированные как байт-код,
5 уровень выводит информацию о всех вызываемых функциях. Примечание - log-файл не удаляется, так что позаботьтесь об этом
сами.
Для пояснения и в качестве рекомендаций - я бы использовал
0 уровень - кто и когда запускал программу, errorsys, вызов критических
операций типа индексации и "перерасчет зарплаты".
1 уровень - какие пункты меню вызывались, какие крупные модули программы
использовались
3 уровень - анализ критических по времени процедур, анализ деятельности
пользователей и подобное, печать документов, доступ к "секретным" данным,
и т.п.