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

AD>Подскажите в чем плюсы и минусы?

Плюсы и минусы — в розетке. Да и там они меняются местами 50 раз в секунду.
Всё зависит от твоих потребностей.

Если тебе нужно время жизни объекта произвольное — то куча, без альтернатив.
Если объекты полиморфные — опять куча. В очень редких случаях можно похимичить с placement new на стеке.
Если объекты большие, и особенно, если функция рекурсивная — снова куча. Чтобы не исчерпать стек.

Если же время жизни "автоматическое" (от входа до выхода из выражения, из блока, из функции), тип известен во время компиляции, и размер небольшой — добро пожаловать на стек.

Здравствуйте, Аноним, Вы писали:

AD>>А обращение (по скорости) различается?
А>в общем случае нет

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

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

A>Здравствуйте, Аноним, Вы писали:

AD>>>А обращение (по скорости) различается?
А>>в общем случае нет

A>На мой взгляд у переменных в стеке больше шансов попасть в кеш, следовательно скорость должна быть быстрее.
Может шансов и больше, но скорость, в моем случае, одинаковая. Я проверял.

Если говорить про Linux — то для начала почитайте http://www.opennet.ru/docs/RUS/kernel2prog/linux_khg_06.html
Я говорю про то, почему это работает быстрее и это определяется на уровне ядра.

Когда вы двигаетесь по стеку ничего не выделяется и всегда есть шанс уйти не туда, куда надо... Работа со стеком осуществляется командами push & pop и регистром esp (для x86 платформы) — не морочьте людям голову. Работа со страницами стека осущствляется функциями ядра, точно так же как и с обычной кучей, только механизм другой и часть памяти под стек выделяется при инициализации процесса.

UN>Когда вы двигаетесь по стеку ничего не выделяется и всегда есть шанс уйти не туда, куда надо... Работа со стеком осуществляется командами push & pop и регистром esp (для x86 платформы) — не морочьте людям голову.
Вообщето так оно и есть. Адресное пространство под стек резервируется единожды при создании потока, и комититься в пределах 1мб по мере необходимости. Освобождение же памяти происходит единожды — при убивании потока (это если конечно самому не освободить себе стек). Стек это нефрагментируемый участок памяти, который резервируется один раз, растет в пределах зарещервированного размера (обычно 1мб), и освобождается при смерти потока.

Создание объекта на стеке это:
sub esp, sizeof(object)
//probe страниц на запись если размер объекта вылазит за размер страницы памяти
mov ecx, esp //а вот и this
call [ecx+constructor_offset]
При этом ядро здесь _может_ дергаться _неявно_ если при обращении память под стек текущего стека начинает нехватать и ядро отращивает потоку стек ловя PAGE_GUARD исключения. Никаких системных вызовов при этом user-mode коду делаьт вообще не нужно.

Убивание объекта на стеке это соответственно:
call [ecx+destructor_offset]
add esp, sizeof(object)
Тут ядро вообще никак не беспокоиться.

Таким образом в коде:

void foo()
{
object o;
}

void main()
{
for(int i=0;i<1024;i++)foo();
}

Рост стека _может_ происходить только при первом вызове foo();



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

void foo()
{
std::aptr<object> o(new object);
}

void main()
{
for(int i=0;i<1024;i++)foo();
}

Здесь вся эта бодяга с менеджером кучи будет повторяться 1024(выделение) + 1024(свобождение) раза.

А я о чем говорю =) Так я и говорю, только я смотрю со сотроны ядра, а они со сотроны процесса — но все равно такты тратятся — так или иначе =)

А в многопоточном такой же механизм старниц этих, как и однопоточном?
И еще вот вопрос: Если объкт создался в стёке, когда я его тестил, его можно смело создавать в стёке в потоках?

Здравствуйте, Аноним, Вы писали:

А>А в многопоточном такой же механизм старниц этих, как и однопоточном?

Да.

А>И еще вот вопрос: Если объкт создался в стёке, когда я его тестил, его можно смело создавать в стёке в потоках?

Да. У каждого потока свой стек, проблемы могут возникнуть при межпотоковом взаимодействии и при обращении к статическим переменным (общим для всех потоков).

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

AD>Подскажите в чем плюсы и минусы?
AD>Спасибо.
Тут про это не сказали, но имхо, стек кешируем, куча нет.

Здравствуйте, Vain, Вы писали:
V>Тут про это не сказали, но имхо, стек кешируем, куча нет.
alzt написал здесь

Автор: alzt
Дата: 21.08.07

:

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

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

UN>Да. У каждого потока свой стек, проблемы могут возникнуть при межпотоковом взаимодействии и при обращении к статическим переменным (общим для всех потоков).

А что за проблемы могут возникнуть?