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

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

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

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

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

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

0

Сообщение от JeyCi это Тип (2): незапланированно долгоживущие выделения памяти ?

"это" - это что именно?

0

Сообщение от DrOffset "это" - это что именно?

касательно storage duration - те, у которых время жизни неправильно ограничивается... имхо...
т.е. по вашему линку надо изучить, как всё по логике... а если её нарушить - то будут косяки со временем жизни - пока беглым взглядом, вижу так...
(пока решаю др sub-задачу практически - скоро дойду до кучи -
? вот кстати объект класса WorkerThread - ГДЕ лучше создать - на стеке или на куче ?? - если таких инстансов планируется подрядить несколько - ведь если большой - то лучше на куче??)

0

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

Ты ошибаешься. Если раскомментарить деструктор, то код будет худо-бедно корректный. Никаких утечек не будет.

0

Сообщение от oleg-m1973 Если раскомментарить деструктор

ведь так и написала - просто там высказала неверно

Сообщение от JeyCi т.е. при раскомментированном том, что в моём примере закомментировано - будет норм

0

Сообщение от JeyCi ведь так и написала - прсто там высказала неверно

Извини, невнимательно прочитал

0

тоже извините не сразу сама поправила
... думаю пока о другом -

Сообщение от JeyCi объект класса WorkerThread - ГДЕ лучше создать - на стеке или на куче ?? - если инстансов этого класса планируется подрядить несколько

Добавлено через 5 минут
... конечно, с разными функциями - ведь можно в фоне выполнять что угодно

Добавлено через 8 минут
вообще - идея наверно глупая - плодить много сущностей...
оставлю инициализацию thread(s) в myGUI, а потом просто move его (их) каждого в thread_guard - чтобы время жизни обоих не противоречило логике их жизненного цикла... имхо

0

Сообщение от JeyCi ... думаю пока о другом - Сообщение от JeyCi объект класса WorkerThread - ГДЕ лучше создать - на стеке или на куче ?? - если инстансов этого класса планируется подрядить несколько

Объект потока, std::thread, создаёшь на cтеке только если ты будешь дожидаться его завершения в этой же функции, либо если ты делаешь ему detach().
Не забывай, что у объектов-на-стеке короткое время жизни и они удаляются автоматически. Соответственно, предавать ссылки на такие объекты в поток надо очень аккуратно.
Внутри же функции потока можешь создавать на стеке (но, помнить о размере).

1

Сообщение от JeyCi могу увидеть - код - когда мне это выгоднее

JeyCi, когда кто-то (не обязятельно вы) делает библиотеку для других, он выгужден думать иначе. Паттерны ругают часто, но это нормально. Бывает, что человек и не ругает а тоже не умеет пользоваться. В этом случае честнее ругать чем не ругать.

Сообщение от JeyCi ну этот в U++ уже вроде под капотом

Тут вроде, С++. Прямо над капотом вымпел - "Си с двумя ветвистыми плюсами над головой". Обратите внимание.

0

Сообщение от IGPIGP делает библиотеку для других,

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

0

Сообщение от JeyCi вот поэтому пока и не вижу смысла...

Опять 25. Так вы назвали бы тему "Когда мне выделять память в случае для..."
И ещё. Любой код для себя, это библиотека для себя. Если в коде больше пары сотен строк, - через год он становится "сторонней библиотекой", когда смотришь и спрашиваешь себя,- "кто это писал?". Но если оно организованно, более-менее прилично, то это очень дружественный жест по отношению к тому, кто смотрит из зеркала.
JeyCi, зачем я вас убеждаю? Уже просто и не знаю. Мне всё больше и больше кажется что вам, конкретно, можно и не выделять память. Контейнеров (со стандартным аллокатором) и смартпойнтеров - хватает? Ну и ладно.

0

Сообщение от IGPIGP JeyCi, зачем я вас убеждаю?

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

0

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

А что такое реллокация? Это выделение памяти через new
Ничего не делает.

0

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

Наверное, имелось ввиду, что, при достаточном reserve, добавление элемента в массив по скорости не отличается от выделения объекта на стеке.

1

Сообщение от JeyCi касательно storage duration - те, у которых время жизни неправильно ограничивается... имхо...

Время жизни ограничивает программист, выбирая тот или иной способ, ориентируясь на тот или иной storage duration

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


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

Сообщение от JeyCi вот кстати объект класса WorkerThread - ГДЕ лучше создать - на стеке или на куче ?? - если таких инстансов планируется подрядить несколько - ведь если большой - то лучше на куче??)

Я бы ориентировался на требуемое время жизни в первую очередь, а потом уже на размер и т.д.

1

Сообщение от JeyCi подрядить несколько - ведь если большой - то лучше на куче??)

Если оно действительно "большой" то просто на стеке не удастся выделить.

1

Сообщение от DrOffset Я бы ориентировался на требуемое время жизни в первую очередь,

значит всё-таки отдельным классом лучше оформлять поток, инстансы которого и смотреть где и как буду жить... и удаляться при выходе из scope'a... включая время жизни локальных и др. переменных и констант этого класса...
вообще логично - а то вдруг захочу весь этот(эти) поток(и) не в GUI выводить, а перекроить на консольный вывод... убедили - если будет разрастаться из утилиты вширь...
а пока живёт в myAppWindow - и scope_guard не нужен...

Добавлено через 31 минуту
storage duration vs lifetime

Storage duration is one of four words: •automatic •static •dynamic •thread (local) That's it. It tells you what rules apply for when the object will be created and destroyed. Lifetime is the portion of the runtime of the program during which the object is usable. Generally this is from construction until destruction, but for trivial types (those with no constructor or destructor) it's "from when the memory is allocated until the memory is either released or used for another object". So the two are related, but they aren't quite the same thing.

и примеры типов storage duration

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

Сообщение от fedorov21951 Сообщение от JeyCi "я поэтому и не хочу связываться со всеми new - потому что даже при выходе из scope непонятно, что потеряю..." можно использовать smart pointers unique_ptr shared_ptr и weak_pr

для ИНФО:
Умные указатели
Сырые указатели и Умные указатели
Как “научить” Указатель определять, что сам Объект уже удален?

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

Сообщение от IGPIGP Контейнеров (со стандартным аллокатором) и смартпойнтеров - хватает? Ну и ладно.

лучше чтобы хватало на первых порах... не хочу пока изобретать даже контейнеры и лезть на более низкий уровень тем более...

Добавлено через 35 минут
и про права владения (это как раз и есть этот new - логично: кто создатель, там и деструктор) - пример:

Сообщение от Nick Alte в том виде, как у тебя это описано, имеет смысл вообще передавать владение функтором классу ComPort: C++ 1 comPort.SetCallbackRx(new MethodFunctor<TestPort>(*this, &TestPort::MyMethod)); Ну и в самом SetCallbackRx, а также в деструкторе ComPort тогда надо предусмотреть уничтожение старого функтора по delete.

p.s.
Передача указателя в класс на объект другого класса

0

вот что, действительно порадовало!

в C++17 (наконец-то!) обычный new должен выделять корректно выровненную память, если тип использует alignas

хоть строка reinterpret_cast(&block) % alignof(Avx_block); и вряд ли будет мной использоваться...
но всё-таки возник вопрос на уточнение - ? выделяя new для каких-нибудь structure или user-defined class objects - обязана ли я делать это выравнивание в принципе ?? или всё уже учтено как-то в моих user-defned классах?... наверно, всё-таки учтено...

0

Сообщение от JeyCi выделяя new для каких-нибудь structure или user-defined class objects - обязана ли я делать это выравнивание в принципе ??

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

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

Сообщение от JeyCi сё уже учтено как-то в моих user-defned классах?

Учтено в реализации new.
Она всегда отдает правильно выровненную память для дефолтного значения выравнивания системы.

1

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

0

Сообщение от JeyCi вот что,

Процитированная ссылка относится к редким для прикладного программиста ситуациям, когда память нужна выровненная специальным образом. Раньше для этого использовались системно-специфичные функции, теперь можно сделать с помощью стандартного new. На этом в общем-то все.

1