#### Новшества в компиляторе и препроцессоре

Все слова начинающиеся на 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, <list ,,,>)    // если level не указан или
        				    первым параметром указано не число,
        				    то данная информация будет выводиться
        				    в log-файл ВСЕГДА не зависимо от
        				    текущего уровня отладки.

Для прикладного логгирования используйте уровни 1-3, 4 уровень дает информацию о вызываемых функциях, скомпилированные как байт-код, 5 уровень выводит информацию о всех вызываемых функциях.
Примечание - log-файл не удаляется, так что позаботьтесь об этом сами.

Для пояснения и в качестве рекомендаций - я бы использовал

- 0 уровень - кто и когда запускал программу, errorsys, вызов критических операций типа индексации и "перерасчет зарплаты".
- 1 уровень - какие пункты меню вызывались, какие крупные модули программы использовались
- 3 уровень - анализ критических по времени процедур, анализ деятельности пользователей и подобное, печать документов, доступ к "секретным" данным, и т.п.

© Ю.Хныкин, uri@itk.ru, 2000