книги хакеры / журнал хакер / специальные выпуски / Специальный выпуск 71_Optimized

Настройка сценария генерации

используй тег code. С помощью этого тега можно задавать примеры кода в твоей документации. Обрати внимание на отступы и форматирование кода примеров. Закрывается пример с помощью тега endcode.

объединяй документацию. Если ты разрабатываешь несколько библиотек, то их документацию ты сможешь хитрым образом интегрировать при помощи механизма ссылок. Также существует возможность встраивать в документацию отдельные документы и изображения. Если немного поковыряться с тегами и настройками, то на выходе можно получить громадный талмуд документации со всеми нужными клиенту данными.

рассмотри возможность использования LATEX. Этот формат позволяет использовать в тексте формулы. Если они тебе строго необходимы для документирования, то без LATEX не обойтись. Внутри тега \f можно задавать формулу с использованием так называемого формата LATEX. Этот тег будет проигнорирован, если в качестве выходного формата используется не LATEX. В общем, латекс велик и вообще рулит.

используй различные схемы определения комментариев. Если ты активно используешь Rational Rose для дизайна архитектуры и постоянно делаешь forward и reverse engineering, то следует обратить внимание на то, что не все комментарии будут ей верно интерпретированы. Например, она проигнорирует символы «/*!», которые маркируют начало комментария для doxygen. Но если твои комментарии начинаются с последовательности «//!», то их роза будет добавлять в генерируемые файлы при forward engineering'е и вставлять в твои сущности модели при reverse engineering'е. Таким образом, тебе не придется постоянно восстанавливать комментарии, и ты сможешь активно модифицировать свою модель и код

www.stack.nl/~dimitri/doxygen/

http://java.sun.com/j2se/javadoc/ http://msdn2.microsoft.com/en-us/library/b2s063f7.aspx www.graphviz.org

генераторы документации.

http://ru.wikipedia.org/wiki/

генератор документации глазами викпедии.

www.interface.ru/borland/bt2006.htm borland together 2006.

ЗАКУЛИСЬЕ СПЕЦ 10-06

стрельба с обеих рук

ПРОГРАММИРОВАНИЕ НА НЕСКОЛЬКИХ ЯЗЫКАХ

ПОД ПРОГРАММИРОВАНИЕМ НА НЕСКОЛЬКИХ ЯЗЫКАХ МЫ БУДЕМ ПОНИМАТЬ РАЗРАБОТКУ ОДНОЙ ПРОГРАММЫ С ИСПОЛЬЗОВАНИЕМ НЕСКОЛЬКИХ ЯЗЫКОВ И ВЗАИМОДЕЙСТВИЕ ПРОГРАММ, НАПИСАННЫХ НА РАЗНЫХ ЯЗЫКАХ

Дмитрий Коваленко

{

__asm{

;кладем на стек eax push eax

;перед тем как ассемблерная вставка кончится, нужно

;снять eax со стека (например,

ñпомощью pop),

;но мы забыли это сделать ;)

}

}

int main()

{

// вызываем функцию... и любуемся сообщением об ошибке :)

Test();

}

И, наконец, если ты пишешь не драйвер, а обыч- ное Win32-приложение, в ассемблерной вставке не должно быть привилегированных инструкций. Вот, пожалуй, и все про inline-ассемблер Visual C++. Тем, кто хочет узнать больше, советуем по- читать MSDN 2006 — там есть вся необходимая информация.

Inline-ассемблер в Delphi во многом похож на inline-ассемблер Visual C++. Поэтому, чтобы не повторяться, мы рассмотрим некоторые моменты вобщем, без особых подробностей. Ассемблерные вставки в Delphi размещаются между asm и end, например:

{обычный код на Pascal} Writeln('Hello!'); {вставка на ассемблере} asm

mov al,1 mov bx,2

end;

{и снова обычный код на Pascal} Writeln('Bye!');

Inline-ассемблер Delphi поддерживает все инструкции вплоть до Pentium 4 и AMD Athlon. Также можно использовать инструкции AMD 3DNow! для AMD K6 и AMD Enhanced 3DNow! для AMD Athlon. К сожалению, поддержки 64-разрядного кода нет, так что про Itanium и x64 можно забыть.

По синтаксису inline-ассемблер Delphi в основном похож на MASM. Например, поддержива-

Если кто не в курсе, OBJ-модуль — это файл с расширением .obj. В OBJ-модуле в специальном формате содержится машинный код, обычно — набор каких-то полезных функций. Функции из OBJ-мо- дулей можно вызывать из программ на Visual C++

èDelphi. Создавать OBJ-модули можно с помощью компиляторов тех же Visual C++ и Delphi. Таким образом, OBJ-модуль, написанный на Visual C++, теоретически может использоваться в программах на Delphi и наоборот.

Но это только теоретически: на практике форматы OBJ-модулей, генерируемых Visual C++

èDelphi, несовместимы между собой. Кроме того, в Visual C++ и Delphi по умолчанию приняты разные соглашения о передаче параметров в функции. Это значит, что компиляторы Visual C++ и Delphi по-разному вызывают функции из OBJ-мо- дулей и генерируют для этого принципиально разный машинный код. Отсюда возникает масса всяких нюансов, описание которых занимает не одну страницу и не две (если кого-то интересуют подробности, то можно посмотреть книгу В. Юрова «Assembler. Учебник»).

Короче, во времена MS DOS OBJ-модули были очень даже отличной штукой, но сейчас это далеко не самый простой способ программирования на нескольких языках.

межпрограммное взаимодействие. Выше мы обсуждали, как «подружить» в одной программе куски кода, написанные на разных языках программирования. Сейчас мы поговорим о том, как «подружить» между собой программы, написанные на разных языках. Под «подружить» имеется ввиду «научить разные программы обмениваться между собой данными».

Начнем с того, что в Windows у каждого процесса есть свое адресное пространство, недоступное другим процессам. С одной стороны, это хорошо — каждый процесс работает в своем адресном пространстве и не мешает другим процессам. С другой стороны, это плохо, потому что если одна программа хочет передать другой какието данные, она не может сделать это напрямую через память. Одним из самых простых решений в этой ситуации является использование memorymapped файлов.

Memory-mapped файл — это, по сути, именованный участок оперативной памяти, к которому может получить доступ любой работающий процесс. Приведем две программы, на примере которых рассмотрим основные методы работы с memo- ry-mapped файлами. Первая программа — MemoryMapped1 — будет создавать memory-mapped файл и записывать в него строчки, введенные с клавиатуры. Вторая программа — MemoryMapped2, будет считывать эти строчки из memory-mapped файла и выводить их на монитор. Обе эти программы будут консольными.

Начнем с первой программы. Сначала напишем ее на Visual C++. Откроем Visual Studio и создадим новое консольное приложение MemoryMapped1.

ЗАКУЛИСЬЕ СПЕЦ 10-06

Использование структур, объявленных на C++ #include <stdio.h>

struct my_str1{ int mem1;

char both; };

struct my_str2{ int mem2;

char both; };

int main()

{

my_str1 str1; my_str2 str2;

__asm{

lea eax, str1 ; заносим в eax адрес str1

;поскольку both есть и в str1 и в str2, для доступа к

;str1.both нужно явно указывать str1

mov [eax]str1.both, 1

;поскольку mem1 есть только в str1, для доступа к str1.mem

;указывать str1 не обязательно

mov [eax].mem1, 1

}

}

Еax не обязательно будет равно 1 #include <stdio.h>

int main()

{

int i;

__asm{

; установим eax в 1 mov eax,1

}

// выведем значение eax printf("EAX=1\n");

__asm{

; присвоим значение eax переменной i mov i, eax

}

//выведем значение eax и убедимся, что оно

//не совпадает с предыдущим printf("EAX=%d", i);

(4)Сразу же отключим в настройках компилятора использование UNICODE. Пропишем в MemoryMapped1.cpp заголовочные файлы windows.h (чтобы можно было без проблем использовать Windows API) и stdio.h:

// заголовочные файлы #include <windows.h> #include <stdio.h>

затем впишем в main() следующий код: int main()

{

// создаем memory-mapped файл HANDLE hFile =

CreateFileMapping(INVALID_HANDLE_VALUE, NULL,\

PAGE_READWRITE, 0, 1024, LPTSTR("DigitalPoem"));

Приведенный выше код вызывает API Create FileMapping, которая создает memory-mapped файл. Коротко остановимся на параметрах, передаваемых в CreateFileMapping. Первый параметр — хендл ранее открытого файла на диске. Никакого файла на диске мы с вами не открывали, поэтому мы передаем здесь INVALID_HANDLE_VALUE. Второй параметр — указатель на структуру SECURITY_ATTRIBUTES, в которой мы

(5)можем установить права доступа к нашему mem- ory-mapped файлу. Ничего особого мы устанавливать не собираемся, поэтому второй параметр у нас 0. Третий параметр — защита (protection) memory-mapped файла. Мы хотим читать и писать memory-mapped файл, поэтому перейдем к константе PAGE_READWRITE. Четвертый и пятый параметр — это двойные слова. Вместе они определяют одно 64-разрядное число — размер memorymapped файла в байтах. Нам хватит одного килобайта, поэтому четвертый параметр (который определяет старшее двойное слово в значении размера) у нас равен 0, а пятый параметр (самое младшее двойное слово в значении размера) равен 1024. И, наконец, пятый параметр «DigitalPoem» — это уникальное имя нашего memorymapped файла.

Если API CreateFileMapping завершилась успешно, в hFile будет находиться хендл созданного файла. В случае неудачи в hFile будет 0. Чтобы отследить это, вставляем в нашу программу проверку:

// ошибка? if(hFile==0)

{

//да, ошибка — выведем сообщение

èзакончим работу

printf("Error! CreateFileMapping returns NULL.\n");

return 0;

}