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

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

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

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

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

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

0

0

Сообщение от Avazart Теперь кому-то стоит почитать еще и про лямбды

ну не с v11, а с v17 удобств прибавилось для работы с this указателем... но сути не меняет

•C++17 - more improvements, especially by handling `this` pointer and allowing `constexpr`. You'll also learn about the overloaded pattern and how to derive from lambda

0

Сообщение от JeyCi а если уж так нужен доступ к аллоцированной памяти для удаления, то чем Deleter в unique_ptr не устраивает?..

Это и будет аналог виртуального деструктора, с той разницей, что тебе придётся таскать его за собой отдельно от экземпляра класса.

0

Сообщение от oleg-m1973 придётся таскать его за собой отдельно от экземпляра класса

но run-time переопределение не нужно будет уже... - ещё вопрос (риторический), что будет тяжелее для run-time... даже не вопрос... и по-моему, вопрос риторический... в unique_ptr'е его (deleter) один раз пришить к указателю, чтобы std его держала при указателе...

0

Сообщение от JeyCi но run-time переопределение не нужно будет уже - ещё вопрос, что будет тяжелее для run-time... и по-моему, вопрос риторический... в unique_ptr'е его один раз пришить к указателю, чтобы std его держала при указателе...

В смысле? Точно такой же указатель на деструктор, только там он хранится в таблице виртуальных методов, а здесь в unique_ptr

Добавлено через 11 минут
И кстати, попробуй-ка сделать какую-нибудь иерархию классов без виртуальных деструкторов, но на unique_ptr с deleter. Думаю, быстро все вопросы отпадут.

0

Сообщение от JeyCi но сути не меняет

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

0

Сообщение от oleg-m1973 И кстати, попробуй-ка сделать какую-нибудь иерархию классов без виртуальных деструкторов, но на unique_ptr с deleter. Думаю, быстро все вопросы отпадут.

Виртульные делетеры? И у каждого виртальный деструктор, кстати. Феерично.

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

Сообщение от Avazart Суть лябд - краткость где это возможно, уместно.

Лябды могут забыкания. Захватывать могут. Но в целом, - да. Они просто не могут заместить то, для чего применяют бетты и гаммы. Фабричные классы и паттерн строитель как более внушительный уровень лямбдам не снился. И не нужно им это. Каждый должен спать со своими мыслями. Лямбдой можно заменить цикл for и сыр рокфор с одинаковым успехом.

0

Сообщение от IGPIGP Фабричные классы и паттерн строитель как более внушительный уровень лямбдам не снился.

Сообщение от Avazart Ну и вообще такое впечатление что Вы несете какую-то дичь.

вы сами с собой разговариваете?...
про то, что с выходом с уровня С на уровень С++, нормальные контейнеры сами нормально скрывают весь хлам - писала выше - вы не перечитываете - пИшите, что не видели, - понятное дело, и я большего не напишу от ненадобности... зачем мне фабрично аллоцировать динамическую память, как ресурс, - так и не убедили... тем более потом возиться с их ptr'ами размазывая это по всей иерархии...

Сообщение от Avazart Приводите примеры кода что бы можно было отвечать конструктивно

- а нет таких пока - по вышеуказанным причинам... и не появятся от ваших неубедительных доводов... время однако...
p.s.
все идеи прозвучали в ветке Архитектура - там ни Фабрикам, ни Строителям места не нашлось... по моим практическим вопросам... свои песочные конструкции пишите сами... себе для run-time'a

Добавлено через 3 минуты
P.S. кстати некоторые - IDE создают без иерархий и без смарт-пойнтеров... и не страдают от этого, а пользуются удобствами compile-time

0

Сообщение от JeyCi P.S. кстати некоторые - IDE создают без иерархий и без смарт-пойнтеров... и не страдают от этого, а пользуются удобствами compile-time

Чего? Отправляйтесь читать что такое IDE и что такое фреймфорк и чем они отличаются.

Сообщение от JeyCi вы сами с собой разговариваете?...

Видимо да.

0

Сообщение от JeyCi P.S. кстати некоторые - IDE создают без иерархий и без смарт-пойнтеров... и не страдают от этого, а пользуются удобствами compile-time

А кто сказал что на Си нельзя всё написать? На ассемблере можно. Ну хорошо-хорошо, - на макроассемблере. И как вы говорите, почить на лаврах, среди тех кто:

Сообщение от JeyCi пользуются удобствами compile-time

Но тут же не Cи и даже не U++. Тут С++(внезапно).

0

Сообщение от Avazart что такое IDE и что такое фреймфорк

да иконка у U++ такая - TheIDE... а по сути, конечно, - Фреймворк...

0

0

если Online Compiler пишется примерно так же (см. url) - то и его как только не назовут...

0

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

- вот кстати без такого, действительно, memory leaks может вылезти (если не указать его, который должен сработать после удаления потомка)...
===
и встретилась интереснейшая идея:

Дизайн большинства std -это параметры шаблона как точки расширения, а не подклассы.

поэтому к иерархиям для полиморфизма я всё-таки всё ещё отношусь скептически...

Сообщение от oleg-m1973 Можно минимизировать использование виртуальных методов при помощи шаблонов, но не более того.

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

Добавлено через 14 минут
P.S.

Сообщение от oleg-m1973 попробуй-ка сделать какую-нибудь иерархию классов без виртуальных деструкторов, но на unique_ptr с deleter. Думаю, быстро все вопросы отпадут.

я вот кстати вообще не помню, чтобы говорила, что если иерархия классов, то при чём-то тут обязательно указатели... пока такую страшилку городить не собираюсь ... последние несколько страниц пишу о том, что всё уже зашили в C++ в классы и даже двигать можно вместо копирования (для скорости и памяти)... и вообще ptr'ы к наследованию в C++ даже не важно уже каким боком... да и наследования пока особо не хочу (практически)... имхо

Добавлено через 4 минуты
ИТОГО:
касательно темы ветки - всё уже выделено в C++

Добавлено через 2 часа 5 минут
P.P.S
да и кстати

«Полиморфное удаление» в основном означает, что std::shared_ptr хранит указатель на функцию, которая уничтожает объект. std::unique_ptr использует «статическое удаление», которое уничтожает объект напрямую.

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

0

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

Конкретно в этом случае, я бы воспользовался std::shared_ptr, параметров шаблона как-то поменьше

1

Сообщение от Avazart Жесть.

Жесть это то чем крыта крыша у чешкой команды. У них совершенно не переносимая система билда, что делает theIDE неким гибридом IDE и фрэймворка. Фреймворк ориентированность зашкаливает.

Сообщение от JeyCi поэтому к иерархиям для полиморфизма я всё-таки всё ещё отношусь скептически...

Полиморфизмов в плюсах - количество. Иерархия - синоним дерева. И это скорее не намёк на того кто придумал родительские отношения из биологической терминологии перенести в программирование. Это больше о ациклических графах. Хотя деревья это тоже о живой органике но ботаника. Любая понятийная модель - дерево. Шаблоны тоже могут образовывать деревья, хотя это ограниченно разнообразием произрастающих типов и их отношениями.

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

Дык если оно вам не нужно, - зачем спрашивать? Про инкрементный билд вы как-то ушли. Не видно понимания борьбы со сложностью построения. Тогда про динамическое связывание вообще и про Pimpl в частности нет смысла читать.
Вы исходите из предпосылки - не понимаю, значит не люблю. Это естественно. Но не всё естественное прекрасно.
Шаблоны очень гибкий инструмент, но они не могут динамически. И они, к тому же, раскрывают код, если предполагают широкое использование в качестве библиотек. Наследование умеет. Но наследование трудно работает с комбинацией свойств. Оно тяготеет к включению намертво и/или комбинаторному росту вариантов сверху вниз.
О том как комбинировать оба подхода можно прочесть у А. Александреску.
Но всё это не про "когда мне выделять память". Это всё про другое.

0

Сообщение от IGPIGP Жесть это то чем крыта крыша у чешкой команды. У них совершенно не переносимая система билда, что делает theIDE неким гибридом IDE и фрэймворка. Фреймворк ориентированность зашкаливает.

Я могу ошибаться но там роде не все срощенно так как C++Builder (хотя и там можно из консоли собирать без IDE)
Да в таком случае и не повод говорить от IDE как о фреймворке.

0

Сообщение от IGPIGP и про Pimpl в частности нет смысла читать.

Уже читала - не такие уж у меня длинные классы, чтобы прятать в них что-то в pointer ради скорости компиляции...

Сообщение от IGPIGP Шаблоны очень гибкий инструмент,но они не могут динамически.

... писала ведь, что больше нравится статически... не та сложность ещё...
да и вроде std::variant для run-time - как альтернатива наследованию

Сообщение от IGPIGP Но наследование трудно работает с комбинацией свойств. Оно тяготеет к включению намертво и/или комбинаторному росту вариантов сверху вниз.

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

0

Судя по https://ru.wikipedia.org/wiki/Ultimate%2B%2B

На самом деле объекты поддержки виджетов существуют в динамической памяти, но они скрыты из области видимости и создаются и уничтожаются автоматически, мы оперируем только с их статическими «обёртками». Это позволяет избавится от ручного управления памятью, вы уже не сможете организовать утечку памяти, забыв написать delete. Хорошая практика программирования с Ultimate++ — никогда не использовать указатели для управления ресурсами. Для управления наборами данных переменного размера или полиморфного типа, используются контейнеры NTL. «Умных указателей» (типа boost::shared_ptr), в NTL нет, они не нужны и считаются плохой практикой. Такой подход к управлению памятью в C++ хорошо зарекомендовал себя, практически не уступая сборке мусора по удобству использования и превосходя её по производительности и детерминированности поведения программы.

Разумно ли предположить что в Ultimate++ не получится создавать элементы управления динамически?

0

Сообщение от oleg-m1973 Конкретно в этом случае, я бы воспользовался std::shared_ptr, параметров шаблона как-то поменьше

с custom_deleter, как посмотрю, вообще можно в неприятности попасть, если он статический

Unless you need to be able to change the deleter at runtime, I would strongly recommend using a custom deleter type. For example, if use a function pointer for your deleter, sizeof(unique_ptr<T, fptr>) == 2 * sizeof(T*). In other words, half of the bytes of the unique_ptr object are wasted.

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

0