Когда выделять память

вот завис в моём понимании этот пункт:

Сообщение от oleg-m1973 в случае динамического выделения памяти. Без которого ты вряд ли сделаешь что-то полезное.

в той же ветке - были даны пояснения

Сообщение от oleg-m1973 В стеке ты не можешь свободно создавать/удалять объекты. Только добавлять в голову и удалять оттуда же. В куче же ты можешь это делать в любой последовательности.

...
когда выделять поток - в принципе поняла,
когда выделять класс - в принципе поняла (чтобы разорвать зависимости)
КОГДА выделять память?.. - всё-таки ещё не всегда очень хочется её выделять, чтобы потом удалять... но даже не в этом суть... а смысл первой цитаты?
поделитесь please опытом кто-нибудь - когда вы выбираете создать объект на стеке, а когда вы выбираете создать объект в куче?. - какие есть предпосылки для вашего выбора?
не хочу потом всё переделывать - а мне всё равно кажется, что на стеке всегда быстрее, а когда и почему лучше куча не знаю... а то ведь могу написать что попало...
логично, что на стеке - определена последрвательность, но ведь при обращении к разным объектам проблем вроде не бывает... имхо... и понятно, что через стек идут параметры функций - так что получается, всё остальное, т.е. вообще всё лучше располагать в куче?
какую проблему можно получить, если всё располагать на стеке? и в каком случае вообще app не запуститься при таком подходе (есть ли такая опасность)?.. есть ли какие-то критерии "must do"? и никак иначе

0

https://www.coursera.org/lectu... -new-jSggV - тут есть немного про это.

1

Сообщение от Avazart Там видимо не про обычный new а про placement new на стеке.

Там про "обычный" new.
На "стеке" мы и так можем начиная с С++11 выровнять память как нам надо с использованием alignas.
А вот "обычный" new всегда возвращает дефолтно-выровненную память. И повлиять на это выравнивание непосредственно было нельзя.

0

Тогда да не совсем понятно зачем это нужно.

0

Avazart, чтобы выровнять динамическую память для работы с SSE, например. При этом стандартными средствами.

Добавлено через 2 минуты
Или для того, чтобы выровнять по единичке динамический буфер, который заведомо будет использоваться в качестве хранилища "сырых" байт. До этого стандартный new все равно делал (мог делать) стандартное выравнивание. В итоге кусочек байт, в количестве от 4 до 16 (в зависимости от) уходил на выравнивание, которое никому не нужно.

0

Вобщем, действительно, - -

Иногда вам нужно реализовать класс, управляющий ресурсом... В большинстве случаев вам не нужно самостоятельно управлять ресурсом, потому что существующий класс, такой как std::string, уже делает это за вас. Пока вы держитесь подальше от сырых указателей, правило трех вряд ли относится к вашему собственному коду.

0

Но это слишком для начинающих.

0

Сообщение от Avazart это слишком для начинающих.

а я и в "сырых" ещё начинающая - и даже начинать пока не хочется, раз есть c++ - пока его осилю...

Сообщение от DrOffset Или для того, чтобы выровнять по единичке динамический буфер, который заведомо будет использоваться в качестве хранилища "сырых" байт.

сырые байты - это, наверно, ещё страшнее, чем сырые указатели... хорошо, что хотя бы в STD всё спрятано в либы... а то управление ресурсами для меня превратилось бы в очень нетривиальную задачку... имхо

0

Сообщение от JeyCi сырые байты - это, наверно, ещё страшнее, чем сырые указатели...

Вот пакет из сети вы получили, или файл открыли и функцией read прочитали - это сырые байты. Т.е. байты, с которыми не ассоциировано никаких типов. С такими байтами работают как с массивом байт, соответственно никакое специальное выравнивание для них не требуется. Т.е. достаточно выравнивания по байтовой границе.

1

всё-таки потоки потоками, а в оперативку (т.е. кучу) вмещаться хочется нормально, а не съедать её всю... за пояснения по "сырым" спасибо, но hand-made allocator я пока точно делать не буду... вектор Фреймворка или array (reading from txt) меня устраивает

0

Сообщение от JeyCi но hand-made allocator я пока точно делать не буду

Хм, а кто-то предлагал вам это делать?

0

ну я же не всегда верю "на-слово" - мне показалось...
=========
просто думаю... вот распараллеливаем, например, задачу - а память ведь может забиться до отказа? - при том что потоки ещё будут стоять в очередь на ядро (да ещё со всем захваченным, получается многократно, контекстом - если потоков много)... не рационально, вероятно, получается...
= это в случае, если каждый поток выделять на куче...

0

Сообщение от JeyCi = это в случае, если каждый поток выделять на куче...

Для каждого потока резервируется память под стек. В Windows, по-умолчанию, это 1Мб.
Но забить память до отказа ты можешь и без потоков. От них это совершенно не зависит.

0

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

0

Сообщение от JeyCi просто подумала, что на куче под 100 потоков резервируется памяти в 100 раз больше, чем под один поток...

Под любые 100 объектов потребуется в сто раз больше памяти, чем под один. Там линейная зависимость. Потоки не исключение.

Добавлено через 1 минуту

Сообщение от JeyCi хотя если функции для них на стеке - то согласна - проблема, вероятно, надуманая...

Нет, не надуманная. Потоки требуют дофига памяти под стек

1

Сообщение от oleg-m1973 Для каждого потока резервируется память под стек. В Windows, по-умолчанию, это 1Мб.

JeyCi, Т.е. 1000 потоков это уже как минимум 1 Гб, и на машине где оперативки мало/загружена - может быть печалька.

1

Сообщение от Avazart и на машине где оперативки мало

ну 1мб стэка CPU и 1гб RAM - это вообще в разных концах света (т.е. материнской платы) - некорректно сравнивать...

0

Сообщение от JeyCi ну 1мб стэка CPU и 1гб RAM - это вообще в разных концах света (т.е. материнской платы)

так-то стек тоже в ОЗУ сидит. Насколько я знаю

1

Сообщение от Алексей1153 тоже в ОЗУ сидит

класс С++ - да,
а CPU - это процессор, у него тоже есть стэк (он маленький и быстрый - 1мб), через который гоняются функции и их аргументы... и, вероятно, объекты расположенные на стэке - всегда так думала - в этом суть ветки - когда это добрО переносить на кучу - в RAM - которая медленнее... (в начале ветки - уже вроде разобрались)

0

Сообщение от JeyCi а CPU - это процессор, у него тоже есть стэк (он маленький и быстрый - 1мб), через который гоняются функции и их аргументы... и, вероятно, объекты расположенные на стэке - всегда так думала - в этом суть ветки - когда это добрО переносить на кучу - в RAM - которая медленнее... (в начале ветки - уже вроде разобрались)

Нет, ты, наверное, перепутала кэш с стеком.
У потока есть стек, у процессора - кэш

0

0