Количественные ограничения, возможные ошибки?

[ezus]

Прошу прощение за упрямство.
С той же темой ( "Как искать ошибки в больших программах?"), но через другую дверь.

Какие известны количественные ограничения  ...?

1. По памяти.

2. С какого момента начинается свопинг и как этот момент можно поймать программно?

3. Программа принципиально рекурсивная, поэтому возможны проблемы со стеком - как это контролировать и этим управлять?

4. Вместо массивов практически везде используются CArray and CMAP. Существуют ли ограничения на количество элементов в этих классах?

5. Существуют ли ограничения на размер CString?

6. Возможно существуют еще какие-нибуть ограничения или причины, по которым программа падает при выполнении десятков или сотен тысяч пробегов внутренних циклов?

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

Спасибо.

[Алексей++]

моё имхо-

3) принципиально - это как ? А по возможности рекурсии лучше избегать, кроме случаев, когда это СИЛЬНО всё упрощает. А контролировать - только в программе, извне - вряд ли
4) не пользовался, не могу ничего сказать
5) об этом не задумывайся
6) кривость рук предшественника

[Finch]

1) ограничение по памяти в 32 разрядной винде 2 гигабата на приложение. Путем нехитрых манипуляций, это число можно довести до 3 гигабайт
2) Когда системе начинает недостовать страниц (4 килобайта) памяти, система сама начинает менее используемые страници скидывать в своп. Поймать этот процесс на уровне пользователя нельзя.
3) В принципе, если не использовать достаточно большие куски памяти под переменные в теле функции, то рекурсивная вложенность в настояший момент довольно большая. И если надо, система может добавлять к стеку память.
4) CArray и CMap не использовал, но если они примерно сделаны по аналогии с STL::map и STL::vector, то насколько я знаю, в них не должно быть ограничений на количество элементов. Только скорость работы должна страдать.
5) Аналогично с 4 пунктом.
6) Причина, как уже говорил, может быть выход за пределы массивов. Если ты начинаеш писать или читать в непредназначенную для этого память, система должна прервать работу программы и выдать сообшение, в Linux например "Segmentation failure". Также возможно, что ты пишеш по несушествуюшим указателям или null указателю.

[Джон]

3) как-то была проблема с одинм проектом в 6ой студии. Делали свой язык программирования, ну и превысили глубину стека.
Лечилось какими-то настройками или опцией компилятора, уже не помню. Но теория такова, что когда ошибка выскакивает просто смотришь матчасть по данной ошибке и всё находишь.

[ezus]

Всем спасибо.
Не подскажите - может быть существуют программы, которые извне могут сказать что-нибуть о бегущей программе? Threads, memory, стек ...

[ezus]

Где можно почитать о работе с дампами?

[Вад]

ezus, утилиту, отображающую нагрузку процесса по потокам (память, время ЦП) с их именами (если именованные) я встречал (вроде, она ещё много полезной информации умела показывать) - увы, не помню названия.
А стек - это, наверное, да, к дампам. Сам с ними особо не работал - только в Linux немного, но там в gdb всё довольно просто было.

[ezus]

Спасибо.