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

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

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

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

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

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

0

Сообщение от JeyCi так и теряется с возрастом навык осваивать новые инструменты - это уже вопрос профпригодности - пиариться тут нечем...

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

0

Сообщение от JeyCi так вы даже линк осилить не смогли, оставленный мной выше (из нового!)...

Это не цитата из стандарта. И в ней не сказано что от STL нельзя наследоваться. Если хотите поговорить о цитатах из учебника, я вас сейчас пошлю читать Дональда Кнута. Вот как освоите написанное в Искусстве программирования, так и рассказывайте басни про "в какой-то там библиотеке любой контейнер реализует random access. И я не буду показывать алгоритм позволяющий сделать random access в красно-черном дереве, так как мне не надо знать какая связь между красно-черным деревом и мапом".

Сообщение от JeyCi ... к чему мне стандарты прошлого века?.. или вы количеством кода (с громким названием "паттерн") собираетесь себе цену набивать...

То есть, про C++20 вы не в курсе и полагаете что стандарты перестали писать в прошлом веке. Что и требовалось доказать о вашем осиляторстве.

1

Похоже у нас на форуме появился новый Fulcrum_013, но женского пола и приверженец не С++Builder а U++.

1

а Всё свелось к тому, что предыдущие ораторы даже Стандарт 98/03 не смогли понять… - начав рисовать свои страшилки на последних нескольких страницах…
А Суть ответа на вопрос ветки сводится к 2м ключевым моментам:
- “Хочешь управлять памятью – пиши на С”;
- Язык С++ - статически типизирован… - основы понятные даже начинающему (но не троллям) – “все типы существуют на этапе компиляции”
ИТОГО:
можно создать простую систему типов (и даже здесь обойтись без явного выделения памяти, отдав – уже отдана - эту ответственность самой библиотеке) и банального Коснструктора почти всегда вполне достаточно, чтобы не разводить панику Фабриками… которые можно, конечно, подрядить для динамической аллокации полиморфных объектов – но вопрос №1 нужен ли вам полиморфизм ценой виртуальности… тогда просто помнить, что виртуальным Коструктор не может быть по сути вещей…
===
Вобщем (адекватным посетителям ветки):
? нужно вам Позднее Связывание – если выбираете реализовывать полиморфизм Наследованием – скатертью дорожка – динамически выделяйте память… чтобы не переживать о том, что нет виртуального Конструктора… можете фабрикой динамически аллоцировать память (и то – лишь в случаях когда даже простого конструктора вам не хватает)…

если смогли реализовать дизайн классов с static creating methods и скомпилировать свой код – а почти всегда можно выехать на Раннем связывании - радуйтесь жизни без головной боли от таких троллей, которые из книжки только название её автора смогли прочитать… чтобы ссылаясь на всех, кого не лень (включая Qt) нести свой бред… и с которыми предметный диалог в принципе невозможен - т.к. предмета не поняли...
===
и вся немощность предыдущих ораторов в понимании, чего они нагородили, и главное – зачем, - становится очевидной – тупо побросались новостаромодными словечками, не удосужившись даже продемонстрировать своё их понимание… и главное – попасть в тему ветки…
и навороты таких иерархий гуру-троллинга, которые в своих игрушках-стрелялках обычно пытаются наделить своих горе-недоделанных-персонажей хоть каким-то функционалом – как правило, и выливается в динамическую аллокацию полиморфных объектов … а по факту в тормоза в run-time’e…
- в эти игрушки они ещё не наигрались – возомнив себя Биллами Гейтсами…

у меня они уже в листе_игнора

Добавлено через 23 минуты
... но практически - не забывать момент scope'ов:

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

0

new

That is why C++, extending C, provided a very strong coupling between allocation and initialization. With a C++ new expression you get either both a successful allocation and a successful complete initialization, or else neither (it cleans up on failure).

Aristotel

As Aristotle would have it, Man is a social animal. Let us developers take example and let our interfaces live together without getting in conflict with each other, and die with dignity, that is, by being sure to be called on their destructors.

Polymorphic clones in modern C++

But the existence of the Interface suggests that there are polymorphic contexts where the object is accessible only via the interface... The tool cut out for solving this problem are smart pointers, and in particular std::unique_ptr.... But let’s consider the case where an implementation inherits from several interfaces. The solution without smart pointers scales effortlessly... But with smart pointers, the situation is different: the clone method, bound to Interface1, cannot be used for Interface2! ...

- всё-таки интересная статья...
p.s.
и главное, мне кажется, я поняла, - всё, что закладываем в compile-time (если речь о templates и даже overloads) - всё-таки раздувает size app'a... а иерархии дают возможность переопределять что-то в run-time'e - и т.к. речь о виртуальных функциях, а функции и их параметры обрабатываются в ЦП, который быстрый! (уже ведь не в прошлом тысячелетии живём)... то соотношение app size(меньше)/speed(примерно на равных) - вполне приемлемо... хотя конечно виртуальный size становится побольше (т.е. ram всё равно кушается при использовании app'a)... -- вот тут для полиморфных классов и приходится динамически выделять память (ведь заранее не знаем, какого child'a придётся подрядить, только в процессе становится известно)... ну и чтобы удалять по-современному - shared_ptr (для полиморфных класов, для MT app'ов, для passing DLL boundaries, recently used cache и преодоления проблемы unreachable memory, если ide не предупредила об утечке памяти) ...
===
только нечего мне пока переопределять, т.к. нет иерархии, подклассы которой должны обрабатываться, как одна сущность, - у каждого класса свой путь... вот и не нуждалась ни в полиморфизме, ни в смарт-пойнтерах... ни тем более в переопределении в run-time'e... ни даже в указателях выходящих из scope'a...
?? думаю, что просто передача обрабатываемых объектов из функции в функцию того же (обрабатывающего) объекта не считается выходом из scope'a - если обрабатываемый объект передаётся в конструктор обрабатывающего объекта...
===
возможно, с перемещением можно поколдовать... но в принципе идиома U++ "всё кому-то принадлежит" ещё не давала сбоев для меня... да и heap там своя... да и разработчики U++ сами в него вносят все новшества языка... поэтому, пока выбираю вариант take-as-is... без чёрной магии move'a и смарт-пойнтеров на чужой куче... раз пока мои несложные задачи прекрасно вписываются в заложенную в U++ концепцию - "всё кому-то принадлежит"...
но вроде они уже и без меня move'ят...

0

Сообщение от JeyCi и главное, мне кажется, я поняла - всё, что закладываем в compile-time (если речь о templates и даже overloads) - всё-таки раздувает size app'a... а иерархии дают возможность переопределять что-то в run-time'e - и т.к. речь о виртуальных функциях, а функции и их параметры обрабатываются в ЦП, который быстрый!

Это всё глубоко второстепенно. Тут главное понять, что большинство ошибок может обнаруживаться в compile-time, при помощи шаблонов и прочего. Такие ошибки и за ошибки-то не считаются, в отличие от тех, которые возникают в рантайме.

1

Сообщение от oleg-m1973 большинство ошибок может обнаруживаться в compile-time, при помощи шаблонов и прочего

однако... весомый аргумент

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

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

хотя цели наследования в принципе разнообразны (не только обобщение подклассов в суперкласс)
- в связи с этим - заключительный вывод:

Use a shared_ptr when you heap-allocate a resource that needs to be shared among multiple objects.

- если всё-аки понадобиться...

0

Сообщение от JeyCi хотя цели наследования в принципе разнообразны (не только обобщение подклассов в суперкласс) - в связи с этим - заключительный вывод:

Я правильно понял - используйте shared_ptr, когда вам нужно, чтоб несколько других объектов контролировали время жизни вашего объекта?

0

Сообщение от oleg-m1973 чтоб несколько других объектов контролировали время жизни вашего объекта?

не контролировали время жизни, а "когда ресурс, выделенный на куче, надо разделить между разными объектами" - т.е. он может использоваться многими co-owners... но правообладатель (жизни) всё равно один - тот, кто выделил память, тому и удалять (просто deleter, или [точнее] указатель на деструктор, пришит к pointer'у)... логично так...
shared_ptr всё-таки имеет copy-семантику... - но не дадо забывать, что речь лишь об указателе!.. сам участок выделенной памяти никаким боком никуда не двигается, пока не будет удалён последний указатель на него - тогда и вызовется deleter, точнее указатель на него пришитый к умному указателю... имхо
в отличие от unique_ptr, имеющего move-семантику - права владения (следовательно, и контроль жизни) на него можно передать другому объекту (вместе с deleter'ом) - но опять же не будет совместных прав владения (и контроля ж.ц.) - владелец всегда ОДИН - будет просто передача эксклюзивных прав собственности на жизнь объекта-под-указателем
===

that's pointless. That's why shared_ptr was introduced - not only because of safety (in terms of avoiding memory leaks), but also because expensive-to-copy objects can be safely shared for (almost) free.

Implementing Our shared_ptr with Move Constructor & Assignment Operator - просто move'ится сам pointer и ref.counter или, если надо, копи-конструктор там тоже есть...
===
===
вот только при наследовании от 2х интерфейсов - там в статье по линку (предыдущего поста) - какие-то расплывчатые ходы unique_ptr'ами в начале (вобщем не дочитала ещё - хочу сама ещё подумать над реализацией такой новинки - если понадобится - но если там речь об интерфейсах - абстрактных классах - то вопрос о том, кто породил отпадает, т.к. нельзя создать объект абстрактного класса - возможно, unique_ptr для наследника тех интерфейсов и создателя и владельца на ж.ц. и нужен - но как он запустит виртуальный деструктор - значит лучше shared_ptr, который в принцмпе для работы с полиморфными объектами ок -- вобщем там ещё статью по линку оттуда дочитать надо...) ... а вообще очень смахивает на C#

0

0

Вот и развязка:
динамический полиморфизм можно заменить статическим полиморфизмом, используя template, как base... но и у этого есть своя цена:

For example, if you are using CRTP with run time object creation, your code may behave weird. Moreover, •As the base class is templated, you can not point derived class object with the base class pointer. •Also, you can not create generic container like std::vector<animal*> because animal is not a class, but a template needing specialization. A container defined as std::vector<animal<dog>*> can only store dogs, not cats. This is because each of the classes derived from the CRTP base class animal is a unique type. A common solution to this problem is to add one more layer of indirection i.e. abstract class with a virtual destructor, like the abstract_animal & inherit animal class, allowing for the creation of a std::vector<abstract_animal*>.

0

Сообщение от JeyCi вот только при наследовании от 2х интерфейсов ... а вообще очень смахивает на C#

Here is how Extract Interface can be implemented with templates

Сообщение от oleg-m1973 большинство ошибок может обнаруживаться в compile-time, при помощи шаблонов и прочего. Такие ошибки и за ошибки-то не считаются, в отличие от тех, которые возникают в рантайме

Сообщение от JeyCi if you are using CRTP with run time object creation, your code may behave weird

How to Make SFINAE Pretty and Robust

0

Сообщение от JeyCi динамический полиморфизм можно заменить статическим полиморфизмом, используя template, как base... но и у этого есть своя цена:

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

1

Сообщение от oleg-m1973 в которых когда-то давно нужно было использовать "динамический полиморфизм",

вот я уже несколько страниц и говорю, что динамический полиморфизм - старый век... и если всё статически типизированным делать... то никакого динамического выделения памяти не надо будет... а статически память выделяется тоже без всяких new самими контейнерами или простыми типами - полями-членами класса...
ну разве что, как указывали, для сохранения lifetime при выходе из scope'a - нужен new...
"Nicely organized class system is enough to avoid dynamic polymorphism in most cases" - понравилась мне эта фраза где-то на просторах сети.....

0

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

В смысле, старый век? Абсолютно нормальная и современная технология. Просто появилась возможность не использовать её там, где не нужно.

0

Сообщение от oleg-m1973 Просто появилась возможность не использовать её там, где не нужно.

можно и так сказать...

0

Сообщение от JeyCi динамический полиморфизм

Сообщение от JeyCi динамического выделения памяти не надо будет

Для динамического полиморфизма совсем не обязательно динамическое выделение памяти. Строго говоря, эти понятия вообще никак не связаны. Это просто сказывается однобокость некоторых источников в интернете или не очень качественных учебников, где динамический полиморфизм преподносится только и исключительно в связке с new.

Сообщение от JeyCi ну разве что, как указывали, для сохранения lifetime при выходе из scope'a - нужен new...

Это не "разве что", а самое главное предназначение динамического выделения памяти: динамически контролировать время жизни. И это нужно довольно часто, явно или неявно.

1

У меня есть два правила.

1) Если можно не выделять память
- Можно, я не буду её выделять.

1.1) Почему ?

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

2) Но если всё таки нужно выделять память?
- То я буду её выделять для строк\массивов(Любого типа) и данных - которые способны динамически изменяться во время работы программы.

1

Сообщение от DrOffset Для динамического полиморфизма совсем не обязательно динамическое выделение памяти.

согласна, что это понятия из разных сфер...
источник динамического полиморфизма - virtual, результат - позднее связывание (кстати не так уж редко встречающееся, например, в том же vba и не так уж плохо работающее - если подключить надо ту же Scripting.Dictionary библу в vba)... в принципе virtual функции и dll-ресурсы - думаю, что сопоставимы по скорости, т.е. медленнее, чем методы статическиех объектов ...

Сообщение от DrOffset главное предназначение динамического выделения памяти: динамически контролировать время жизни.

+1

Сообщение от Ligren Но если всё таки нужно выделять память? - То я буду её выделять для строк\массивов(Любого типа) и данных - которые способны динамически изменяться во время работы программы.

- а это уже как раз может быть зашито в библиотеку - т.е. сам аллокатор и выделение указателя на выделенную память... я вот не вижу смысла динамически выделять память для вектора... как это когда-то надо было (да и сейчас) для массива... - лишняя головная боль с удаление (даже смарт-пойнтерами)...
ну или в wrapper можно завернуть контейнер - но тоже не вижу необходимости для вектора - только если по причине, указанной DrOffset, - в принципе, так класс можно сделать более универсальным ("хотя писать код про запас - вредно" )
...имхо - оставновилась пока на таком видении...
p.s.
просто вот передаю строку из одного метода-члена в другой метод-член класса... результат - массив вектор (и далее по тексту тоже), который надо приклеить к массивувектору-полю-члену того же класса, что в принципе и делаю в этом 2-м методе (после нужной обработки входящей строки)... а сам общий массив всё ещё обрабатывается в 1-й функции... логично подхватывая и вставленный довесок (! не параллельно)... не могу понять может ли куда-то что-то исчезнуть в такой ситуации??.. - достаточно ли вектора (члена того-же класса)?.. или надо динамически выделить для него память и работать с указателем (но по сути контейнер NTL)...
как только поставлю тормоза - всё работает... тормоза убираю - получаю отработку по началу массива и по последней загруженной во 2-й метод строке и массива выданного из неё... а данные между (др. строки, которые тоже должны вернуться из 2-го метода массивами) - теряю... когда нет тормозов...
причины могут быть разные - от скорости сети, вариаций с константностью, реакции сервера на запросы, колотящие по нему, чужая куча и всё что угодно...
вот и думаю:
- то ли эту обработку строки (во 2-м методе-члене) вынести в отдельный интерфейс и наследовать от него (хотя толку не вижу - он мне больше нигде не нужен)... вроде по правилам SingleResponsibility или InterfaceSegregation надо бы, но (толку... см. предыдущие скобки)...
- то ли что-то где-то теряю при выходе из scope'а - хоя scope'а всего-то 2 - 2 метода-члена класса (внутри которых scope'ов вроде нет) и 1 вектор член того же класса... в который по кругу: дописываются элементы из 2-го метода + сам он обрабатывается 1-ым методом... надо ли здесь выделить динамически память для этого вектора-поля-члена класса?.. или проблема в другом?...
- то ли с константностью нагрешила - но ведь начало вектора и конец (последняя загруженная во 2-й метод строка и вернувшийся довесок к вектору-члену класса) обрабатываются нормально...
просто интересно... гадать не надо, код не просите - но разобраться интересно - если кто знает...
хотя с тормозами (sleep(5)) в момент обращения к серверу (до или после) работает всё... пока совсем не "access denied" (наверно, там сервер сам уже динамически решает, когда его уже достало количество клиентов и их запросы, - вот и получается "повезёт-не повезёт" успеть до "access denied" - но это детали - это и так понятно)... сервер тоже не просите - не мой...

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

Сообщение от JeyCi 2 метода-члена класса (внутри которых scope'ов вроде нет)

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

0

Сообщение от DrOffset ... а потом уже на размер и т.д.

имеются наблюдения

0