И var будет всегда генериться как var. А ещё лучше в данном случае использовать extern C и для переменных также.

После имени функции говорит о том, что Вaтком использует передачу параметров в регистрах. От этого помогает cdecl перед именем функции.

Пример:

extern C int cdecl my func();

Скажите почему возникает stack overflow и как с ним бороться?

Причины:

1. Велика вложенность функций

2. Слишком много локальных переменных (или большие локальные массивы);

3. Велика глубина рекурсии (например, по ошибке рекурсия бесконечна)

4. Используется call-back от какого-то драйвера (например, мыши);

В пунктах с 1 по 3 - проверить на наличие ошибок, по возможности сделать массивы статическими или динамическими вместо локальных, увеличить стек через stklen (для C++), проверять оставшийся стек самостоятельно путем сравнения stklen с регистром SP.

В пункте 4 - в функции, использующей call-back, не

проверять стек; в связи с тем, что он может быть очень мал - организовать свой.

Любители Ваткома! А что, у него встроенного ассемблера нет что ли? Конструкции типа asm не проходят?

Встроенного asma у него на самом деле нет. Есть правда

возможность писать asm-функции через #pragma aux

Например:

#pragma aux DWordsMover = \ mov esi, eax , \ mov edi, ebx , \ jcxz @@skipDwordsMover , \ rep movsd , \ @@skipDWordsMover: , \ parm [ebx] [eax] [ecx] modify [esi edi ecx]

void DWordsMover

(void* dst, void* src, size t sz);

При создании 16-bit OS/2 executable Watcom требует либу DOSCALLS.LIB. Причем ее нет ни в поставке Ваткома ни в OS/2. Что это за либа и где ее можно достать?

Называют ее теперь по другому. В каталоге LIB286 и LIB386 есть такая OS2286.LIB. Это то, что вам нужно. Назовите ее DOSCALLS.LIB и все.

BC не хочет понимать метки в ассемблерной вставке - компилятор сказал, что не определена эта самая метка. Пришлось определить метку за пределами ASM-блока. Может быть есть более корректное решение?

Загляните в исходники RTL от C++ 3.1 и увидите там нечто

красивое.

Например:

#define I asm

........

I or si,si I jz m1

I mov dx,1 m1: I int 21h

и т.д.

Есть - компилировать с ключом -B (via Tasm) aka #pragma

inline. Правда, при этом могут возникнуть другие проблемы: если присутствуют имена read и read (например), то компилятор в них запутается.

Б1о замечено, что Борланд (3.1, например) иногда генерит разный код в зависимости от ключа -B.

Как правило, при его наличии он становится осторожнее - начинает понимать, что не он один использует регистры.

Почему при выходе из программы под BC++ 3.1 выскакивает Null pointer assignment ?

Это вы попытались что-то записать по нулевому адресу памяти, чего делать нельзя.

Типичные причины:

используете указатель, не инициализировав его.

Например:

char *string; gets(string);

запрашиваете указатель у функции, она вам возвращает NULL в качестве ошибки, а вы этого не проверяете.

Например:

FILE *f = fopen( gluck , w ); putcCX, f); Это сообщение выдаётся только в моделях памяти Tiny, Small, Medium.

Механизм его возникновения такой: в сегменте данных по нулевому адресу записан борландовский копирайт и его контрольная сумма. После выхода из main контрольная сумма проверяется и если не совпала - значит напорчено по нулевому адресу (или рядом) и выдаётся сообщение.

Как отловить смотрите в HELPME!.DOC - при отладке в Watch поставить выражения:

*(char*)0,4m (char*)4

потом трассировать программу и ловить момент, когда значения изменятся.

Первое выражение - контрольная сумма, второе - проверяемая строка.

При запуске программы из BC (Ctrl-F9) все работает нормально, а если закрыть BC, то программа не запускается. Что делать?

Если вы используете BWCC, то эту либу надо грузить

самому - просто среда загружает BWCC сама и делаёт её

доступной для программы. Советуем вам пользоваться таким

макросом:

#define BEST EnableBWCC(TRUE); \ EnableCtl3d(TRUE); \ EnableCtl3dAutosubclass(TRUE) Потом в InitMainWindow пишете: BEST; и все будет хорошо.

Вообще-то правильнее OWLевые экзепшены ловить и выдавать сообщение самостоятельно. Заодно и понятнее будет отчего оно произошло: