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

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

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

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

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

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

0

Сообщение от JeyCi когда вы выбираете создать объект на стеке, а когда вы выбираете создать объект в куче?. - какие есть предпосылки для вашего выбора? не хочу потом всё переделывать - а мне всё равно кажется, что на стеке всегда быстрее, а когда и почему лучше куча не знаю... а то ведь могу написать что попало...

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

Добавлено через 1 минуту
Размер стека ограничен, т.е. большие объекты/массивы лучше выделять на куче

1

JeyCi,
при выходе из функции память в стеке освобождается. Все локальные переменные хранятся в стеке.
например:
Такой код вызовет ошибку времени исполнения - при выходе из метода память под переменную a будет удалена, а ссылка будет указывать на мусор.
Поэтому для этого надо выделять память, а потом удалять ее

1

Сообщение от fedorov21951 при выходе из функции память в стеке освобождается.

Чем? Она была выделена?

Сообщение от fedorov21951 Такой код вызовет ошибку времени исполнения

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

2

Сообщение от fedorov21951 при выходе из метода память под переменную a будет удалена, а ссылка будет указывать на мусор. Поэтому для этого надо выделять память, а потом удалять ее

этот пример вероятно про то, что вы имели ввиду - dangling reference
- я поэтому и не хочу связываться со всеми new - потому что даже при выходе из scope непонятно, что потеряю... (ведь приходится иногда уж достаточно сильно закручивать код логически, да ещё всякие Exceptions можно словить - не норм. выходы бывают)...
поэтому интересуюсь, когда же всё-таки БЕЗ new/delete никак не прожить... всегда старалась их избегать - но настало, наверно, время - расширять свой арсенал... - чтобы в полную силу реализовывать с++, а в чём сила использования кучи - не знаю...?

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

Сообщение от oleg-m1973 Объект на стеке будет удалён сразу при выходе из области видимости. Если тебе нужны более долгоживущие объекты, выделяешь их на куче.

вот об этом ещё не думала... спасибо!

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

Сообщение от oleg-m1973 большие объекты/массивы лучше выделять на куче

- да, это помню

0

Сообщение от JeyCi я поэтому и не хочу связываться со всеми new - потому что даже при выходе из scope непонятно, что потеряю...

можно использовать smart pointers unique_ptr shared_ptr и weak_pr

1

Сообщение от JeyCi а в чём сила использования кучи - не знаю...?

Наверное в том что можно больше объема выделить(чем на стеке)?
Можно его вернуть когда не надо. Да и главное можно выделить ровно столько сколько нужно на данный момент времени.

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

Сообщение от JeyCi поэтому интересуюсь, когда же всё-таки БЕЗ new/delete никак не прожить

Там где нужна полиморфность ?
Например приложение с Qt будет содержать обязательно new

1

Сообщение от oleg-m1973 Объект на стеке будет удалён сразу при выходе из области видимости

static не будет. и смотри код ниже.

Сообщение от fedorov21951 int a = 5; return &a;

А если так:

Сообщение от Avazart Наверное в том что можно больше объема выделить(чем на стеке)?

Сообщение от JeyCi что на стеке всегда быстрее,

25 тактов вместо 10? Забейте на это.

0

Сообщение от Vladimir. static не будет. и смотри код ниже.

static не на стеке выделяется. И что там ниже я должен увидеть?

Сообщение от Vladimir. 25 тактов вместо 10? Забейте на это.

Это ты об чём вообще, какие 25 тактов?

0

Сообщение от Vladimir. 25 тактов вместо 10? Забейте на это.

Если посчитать то в 2.5 раза ? Или у Вас другая арифметика?

Добавлено через 12 минут
И да на стеке быстрее, с этим нельзя не считаться, даже если не используешь new/delete явно.
Именно по этому стоит делать у вектора reserve перед тем как добавлять элементы если кол-во элементов можно предсказать.

0

JeyCi, бываает не только полиморфизма для, нужен указатель на кучу. Бывает (по разным причинам, не только singleton) нужно закрыть конструкторы, а создание объектов делегировать фабрике или фабричному классу. Эти друзья (они и вправду друзья) могут выделить память в куче и разместить там placement new объект и вернуть указатель. Указатель может быть и мудрым в том числе.

0

Сообщение от oleg-m1973 И что там ниже я должен увидеть?

что созданная автоматически переменная продолжает жить за пределами скоупа функции при присваивании константной ссылке.

Сообщение от Avazart Если посчитать то в 2.5 раза ? Или у Вас другая арифметика?

Не тот уровень задач, когда это имеет значение. К тому же можно делать ленивые вычисления или выделять память блоками под несколько объектов, если их количество большое. Я не оспариваю аргумент, а утверждаю, что его значимость в данном случае невелика.

0

Сообщение от Vladimir. что созданная автоматически переменная продолжает жить за пределами скоупа функции при присваивании константной ссылке.

Заблуждение.

Добавлено через 56 секунд

Сообщение от Vladimir. Не тот уровень задач, когда это имеет значение. К тому же можно делать ленивые вычисления или выделять память блоками под несколько объектов, если их количество большое. Я не оспариваю аргумент, а утверждаю, что его значимость в данном случае невелика.

Я не понимаю что Вы тогда утверждаете.
Если можно создать на стеке стоит создавать на стеке для этого кажется есть даже специальные контейнеры. Если же нет - то нет.
О какой значимости Вы говорите не понятно.

0

Avazart,

Заблуждение.

Возможно. Тем не менее, потратьте 10 минут на изучение вопроса.

Сообщение от oleg-m1973 static не на стеке выделяется.

А где тогда?

Сообщение от Avazart О какой значимости Вы говорите не понятно.

У нас получилось "долларовое обсуждение для идеи на четвертак". Я говорю, что делать нужно как удобнее, а не как быстрее.

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

0

Сообщение от Vladimir. А где тогда?

В процессе есть специальная область данных для них.
Но тут важнее не где именно, а какой тип storage duration.
И что так стоит возвращать только константные "сущности" иначе могут быть проблемы при вызове из нескольких потоков.

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

Сообщение от Vladimir. У нас получилось "долларовое обсуждение для идеи на четвертак". Я говорю, что делать нужно как удобнее, а не как быстрее.

Удобно это субъективное слово. Делать нужно как требует та или иная ситуация.

0

Сообщение от Vladimir. К тому же можно делать ленивые вычисления

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

Сообщение от Vladimir. делать нужно как удобнее, а не как быстрее.

спорно - всегда нужен баланс между скоростью и удобством и чем-то приходится жертвовать ради другого...

Сообщение от oleg-m1973 static не на стеке выделяется

вроде global на стеке выделяется... и когда exception или просто выход из app, то он вроде и не unwind - так и возникают memory leaks, если не ошибаюсь...
ну или так - в случае неудаления объекта:
а при закомментированном деструкторе - норм.
а вообще - спасибо за дискуссию

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

Сообщение от IGPIGP а создание объектов делегировать фабрике или фабричному классу.

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

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

Сообщение от IGPIGP не только singleton

ну этот в U++ уже вроде под капотом

One is a container capable of containing none or single element of type specified as template argument or derived from it.

0

Сообщение от Avazart И да на стеке быстрее, с этим нельзя не считаться, даже если не используешь new/delete явно. Именно по этому стоит делать у вектора reserve перед тем как добавлять элементы если кол-во элементов можно предсказать.

вот оно что, а я-то дурак думал, что это чтобы реаллокаций меньше было.
а можете мне, криворукому, пояснить, что делает reserve со стеком?

0

6 Tips to supercharge C++11 vector performance

Сообщение от GbaLog- #1 Avoid unnecessary reallocate and copy cycles by reserving the size of vector ahead of time.That’s a performance gain of 75.14% !!!

Добавлено через 5 минут
я по Деструктору вектора обычно - полагаю, что такой вариант самый правильный (сначала clear, потом swap)...
по Конструктору - сразу резервировать с запасом - чтобы не увеличивать каждый раз... при необходимости - увеличивать сразу на N элементов - очевидно ведь, что будет быстрее, чем увеличить N раз по одной штуке...

Сообщение от Tulosba reserve изменяет ёмкость, а resize - размер.

...

0

Сообщение от JeyCi вроде global на стеке выделяется... и когда exception или просто выход из app, то он вроде и не unwind - так и возникают memory leaks, если не ошибаюсь... ну или так - в случае неудаления объекта: C++ 1 2 3 4 5 6 7 8 9 10 11 12 struct Foo {    byte *ptr;      //~Foo() { if(ptr) delete[] ptr; } // this might be missing    ~Foo() {} };   Foo foo;   CONSOLE_APP_MAIN {    foo.ptr = new byte[1000]; } а при закомментированном деструкторе - норм.

https://en.cppreference.com/w/... e_duration

0

Сообщение от DrOffset https://en.cppreference.com/w/... e_duration

по Static local variables почитаю - спасибо...
***
Три вида утечек памяти
? полагаю, по линку cppreference - это Тип (2): незапланированно долгоживущие выделения памяти ?

мой же пример - это, вероятно, Тип(1) - "Кто-то выделил память при помощи new или malloc, и так и не вызвал free или delete, чтобы высвободить память по окончании работы с ней." - т.е. при раскомментированном том, что в моём примере закомментировано - будет норм
p.s.
Тип (3): свободная, но неиспользуемая или непригодная для использования память
- это, похоже, тот же свободный хвост после vector reserve - если его не занять чем-нибудь или не shrink_to_fit

0