Что-то я запуталась
Выделяла память раньше через new и не заморачивалась
а тут как обухом по голове

Расскажите, коли кому не лень, в чем фундаментальные отличия в выделении памяти в куче и на стеке?
2. что быстрее?
3. что безопаснее?
4. какие есть подводные камни?
5. какими функциями выделять лучше? станадратный new,alloc или что из Win32API или еще чего юзать.

6. может еще какие места выделения памяти есть?
7. Какой прок от отображаемых в память файлов? Насколько это плохо, при работе по сети?

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

L>в чем фундаментальные отличия в выделении памяти в куче и на стеке?
L>2. что быстрее?

Быстрее в стеке. Один из регистров всегда указывает на стек, поэтому обычно достаточно одной команды CPU.

L>3. что безопаснее?

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

L>4. какие есть подводные камни?

Большие объёмы данных в стеке (для x86 больше страницы — 4К) выделять нужно осторожно, иначе можно получить accass violation. Компиляторы обычно эту проблему берут на себя.

L>5. какими функциями выделять лучше?

Для каждого случая своё. Стек (автоматические переменные) используются когда достаточное время жизни ограничено блоком (функцией). Куча используется для размещения данных которые должны жить дольше, чем работает какая-то одна функция.

L>станадратный new,alloc или что из Win32API или еще чего юзать.

Для плюсов — new, для plain C — malloc. Если нет crt или необходимо эффективно с памятью работать, можно и VirtualAlloc использовать.

L>6. может еще какие места выделения памяти есть?

static. Иногда достаточно определить большой масив char и использовать его как кучу.

L>7. Какой прок от отображаемых в память файлов?

Работать с такими файлами в ряде случаев намного проще (доступ по указателям), чем читать по байту из потока.

L>Насколько это плохо, при работе по сети?

См для примера ремарки к CreateFileMapping:

The exception has to do with remote files. Although CreateFileMapping works with remote files, it does not keep them coherent. For example, if two computers both map a file as writable, and both change the same page, each computer will only see its own writes to the page. When the data gets updated on the disk, it is not merged.

Для сетевых вайлов маппинг по сути эмулируется предварительным чтением в буффер, поэтому он не имеет эффективной поддуржки со сторны менеджера памяти ОС, как маппинг физических файлов с локального диска.

PS: а где вопрос №1 ? .

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

L>7. Какой прок от отображаемых в память файлов? Насколько это плохо, при работе по сети?

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

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

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

Аллоцируемая память может быть "отброшена" менеджером — содержимое теряется и физические страницы отдаются другому процессу, а когда к памяти произойдёт доступ, менеджер подкачает страницы непосредственно из отображаемого файла. Неподкачиваямая память практически только в ядре есть и ещё в каких-нибудь специфических случаях.

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

L>6. может еще какие места выделения памяти есть?

Еще есть такая функция — alloca. Синтаксис подобен malloc. Но память выделяется в стеке и доступна до тех пор, пока не выйдем из функции, в которй этот вызов alloca сделан. Функция очень быстрая, но большие объемы запрашивать не стоит — стек по умолчанию имеет размер всего 1Мб максимум.
.

Забыл добавить. Освобождать эту память не надо. При выходе из функции, вызвавшей alloca, память сама освободится.

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

PD>Еще есть такая функция — alloca. Синтаксис подобен malloc. Но память выделяется в стеке и доступна до тех пор, пока не выйдем из функции, в которй этот вызов alloca сделан. Функция очень быстрая, но большие объемы запрашивать не стоит — стек по умолчанию имеет размер всего 1Мб максимум.

То что надо!
Жаль только при ее использовании придется исключения юзать

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

L>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Еще есть такая функция — alloca. Синтаксис подобен malloc. Но память выделяется в стеке и доступна до тех пор, пока не выйдем из функции, в которй этот вызов alloca сделан. Функция очень быстрая, но большие объемы запрашивать не стоит — стек по умолчанию имеет размер всего 1Мб максимум.

L>То что надо!
L>Жаль только при ее использовании придется исключения юзать

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

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


L>Жаль только при ее использовании придется исключения юзать

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

L>>Жаль только при ее использовании придется исключения юзать
ssm>

Дело в том, что по NULL не отловить проблемы в выделении памяти

_alloca
Allocates memory on the stack.

void *_alloca( size_t size );
Parameters
size
Bytes to be allocated from stack
Return Values
The _alloca routine returns a void pointer to the allocated space, which is guaranteed to be suitably aligned for storage of any type of object. To get a pointer to a type other than char, use a type cast on the return value. A stack overflow exception is generated if the space cannot be allocated.

Remarks
_alloca allocates size bytes from the program stack. The allocated space is automatically freed when the calling function exits. Therefore, do not pass the pointer value returned by _alloca as an argument to free.

There are restrictions to explicitly calling _alloca in an exception handler (EH).

EH routines that run on x86-class processors operate in their own memory frame: They perform their tasks in memory space that is not based on the current location of the stack pointer of the enclosing function.

The most common implementations include Windows NT structured exception handling (SEH) and C++ catch clause expressions. Therefore, explicitly calling _alloca in any of the following scenarios results in program failure during the return to the calling EH routine:

Windows NT SEH exception filter expression: __except ( alloca() )
Windows NT SEH final exception handler: __finally { alloca() }
C++ EH catch clause expression
However, _alloca can be called directly from within an EH routine or from an application-supplied callback that gets invoked by one of the EH scenarios listed above.

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

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

L>>6. может еще какие места выделения памяти есть?

PD>Еще есть такая функция — alloca. Синтаксис подобен malloc. Но память выделяется в стеке и доступна до тех пор, пока не выйдем из функции, в которй этот вызов alloca сделан. Функция очень быстрая, но большие объемы запрашивать не стоит — стек по умолчанию имеет размер всего 1Мб максимум.
PD>.


не вижу понтов в этой функции....
достаточно обьявить статический массив и юзать его...
Ваше мнение-

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

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

L>>7. Какой прок от отображаемых в память файлов? Насколько это плохо, при работе по сети?

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

Отображаемые страницы могут быть вытеснены в swap, после этого освобожденные page frames будут отданы под страницы других процессов.

Один из плюсов отображаемых файлов по сравнению со считыванием файла в память это то, что в первом случае, если страницы не были изменены (т.е. происходит только чтение), при вытеснении страниц, занимаемых отображаемым файлом, в swap, эти страницы не придется записывать на диск, т.е. сам файл на диске является swap'ом.

M>не вижу понтов в этой функции....
M>достаточно обьявить статический массив и юзать его...
M>Ваше мнение-

"понты" в том что размер определяется динамически
этим способом часто пользуются функции преобразующие строки ANSI в UNICODE и обратно

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

M>>не вижу понтов в этой функции....
M>>достаточно обьявить статический массив и юзать его...
M>>Ваше мнение-

A>"понты" в том что размер определяется динамически
A>этим способом часто пользуются функции преобразующие строки ANSI в UNICODE и обратно

Мои 5копеек:

void foo( size_t size )
{
    BYTE    *pBuff = static_cast<BYTE*>( ::_alloca( size ) );
}

void bar( const size_t size )
{
    BYTE    pBuff[ size ];
}

bar() — не скомпилируется

L>>>Жаль только при ее использовании придется исключения юзать
ssm>>

L>Дело в том, что по NULL не отловить проблемы в выделении памяти

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

если же произошло нечто ужасное (место под своп = 0) , выкинется эксепшн, нам останется только отлогировать
ошибку и завершить выполнение программы.

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

L>>>>Жаль только при ее использовании придется исключения юзать
ssm>>>

L>>Дело в том, что по NULL не отловить проблемы в выделении памяти

A>а зачем там проверять на нулл? функции распределения памяти в современных ОС
A>с виртуальной памятью могут всегда выполняться успешно т.к. память выделяется странично, и страница
A>может физически не выделяться до тех пор пока не произойдет обращение к ней.
A>это т.н. механизм lazy commit

A>если же произошло нечто ужасное (место под своп = 0) , выкинется эксепшн, нам останется только отлогировать
A>ошибку и завершить выполнение программы.
Речь идет о выделении памяти на стеке, виртуальная память, своп и прочие чудеса распределния памяти в современных ОС к этому отношения не имеют.

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

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

M>>>не вижу понтов в этой функции....
M>>>достаточно обьявить статический массив и юзать его...
M>>>Ваше мнение-

A>>"понты" в том что размер определяется динамически
A>>этим способом часто пользуются функции преобразующие строки ANSI в UNICODE и обратно

S>Мои 5копеек:

S>

S>void foo( size_t size )
S>{
S>    BYTE    *pBuff = static_cast<BYTE*>( ::_alloca( size ) );
S>}

S>void bar( const size_t size )
S>{
S>    BYTE    pBuff[ size ];
S>}
S>

S>bar() — не скомпилируется
Если это С, то скомпилируется.

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

S>Мои 5копеек:

S>

S>void foo( size_t size )
S>{
S>    BYTE    *pBuff = static_cast<BYTE*>( ::_alloca( size ) );
S>}

S>void bar( const size_t size )
S>{
S>    BYTE    pBuff[ size ];
S>}
S>

S>bar() — не скомпилируется

Если компилятор поддерживает С99, в частности variable length arrays, то скомпилится на-ура. Один из таких компиляторов — gcc.

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

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

S>>Мои 5копеек:

S>>

S>>void foo( size_t size )
S>>{
S>>    BYTE    *pBuff = static_cast<BYTE*>( ::_alloca( size ) );
S>>}

S>>void bar( const size_t size )
S>>{
S>>    BYTE    pBuff[ size ];
S>>}
S>>

S>>bar() — не скомпилируется

ME>Если компилятор поддерживает С99, в частности variable length arrays, то скомпилится на-ура. Один из таких компиляторов — gcc.

Уважаемы Сэры, таки правы

Мой, пробел о С — не подумал.

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

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


Век живи век учись....

а вот _alloca мне точно пригодится за то и спасибо....

A>>"понты" в том что размер определяется динамически
A>>этим способом часто пользуются функции преобразующие строки ANSI в UNICODE и обратно

S>Мои 5копеек:

S>

S>void foo( size_t size )
S>{
S>    BYTE    *pBuff = static_cast<BYTE*>( ::_alloca( size ) );
S>}

S>void bar( const size_t size )
S>{
S>    BYTE    pBuff[ size ];
S>}
S>

на VC такое точно не схавается

S>bar() — не скомпилируется