Здравствуйте, vasketsov, Вы писали:

V>Здравствуйте, grapes, Вы писали:

G>>пере-х стек перепелнила — такого еще не случалось (на моем веку)
V>Счастливый! (Или молодой? )
V>Переполнение стека — серезная проблема, она существует с самого начала вычислительной техники, ибо стек — это базовая форма хранения данных. Используется кроме всего прочего, из-за огромной скорочти выделения памяти (фактически, она уже выделена, просто указатель сдвигается). Естественно, она виртуальная, других и не бывает на самом деле, просто ее явно обычно не выделяют, поэтому так говорить не принято.
На платформах IBM PC обычно (т.е. в Win) весь стек нити сразу оказывается в виртуальном адресном пространстве процесса. Причем старшая по адресу незаполненная страница памяти имеет флаг PAGE_GUARD, а все остальные незаполненные страницы так вообще процессу не доступны (Access violation), физическая память для них еще не выделена. Когда происходит первое обращение к этой старшей странице, вызывается обработчик, который делает эту страницу доступной, выделяет следующую страницу с младшим адресом и на нее ставит флаг PAGE_GUARD. Этот обработчик можно даже перепрограммировать, но я не пробовал.
Интересно поисследовать, каковы потери в быстродействии из-за этого обработчика.
Интересно, что memcpy заполняет память от младших адресов к старшим. Но вот при использовании ее в конструкторе копирования больших (в несколько страниц) объектов на стеке все работает без Access violation. То есть, прежде чем такой конструктор вызовется, все необходимые страницы памяти под локальные переменные уже будут созданы! Это тоже потеря быстродействия?