ДохтаРLumix что касается примеров b() = new A, то это просто заглушка. в реале на уровне пользователя используются только функции b() = a(); и пользователь не должен думать, что же там под капотом происходит и не потечет ли у него что-нибудь...


Есть такой патерн , называется виртуальный конструктор,
Делайте там методы create_object, get_object, delete_object итд
и пусть через него кто как хочет тот так и управлеяет обьектами.
Какую сигнатуру определите так и будет управляться.

Зачем вы нам пудрите мозги с желанием запрятать под капот указатели и ссылки.
Прячьте их под патерн.

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

Объясните мне что именно вы имели ввиду под "create_object, get_object, delete_object"??? и я сделаю это

если вы имели ввиду давать эти методы в руки пользователей, то это 100% НЕТ!! задача стоит чтобы они вообще забыли, что работают с какими-то объектами, что надо какую-то память выделять и что есть какие-то правила при переносе объектов между функциями. все это надо скрыть навсегда

пользователи не должны управлять объектами!!

попробуйте попрограммировать на яваскрипте и поймете, что я имею ввиду

maytonА ты не боишся что требование удалять сразу является ударом по производительности?
Может быть создатели GC были не дураки и неспроста сделали освобождение памяти
для обнулившейся ссылки (обнулившийся счётчик связей) отложенным? Ты думал об этом?


1. Нет, я этого не боюсь
2. Я оооочень серьезно обдумал все это. Первый раз когда я задумался "о смысле жизни"))) то есть о памяти, о gc и все такое это было где-то 2008-2009 год. То есть я так или иначе возвращаюсь к этой теме уже 3-4 года, потому что каждый новый успешно реализованный проект дает возможность посмотреть на эти задачи под новым более широким углом и соотв. решать более красиво.

насчет "мудрости GC архитекторов"...
ответ на ваш вопрос очень прост: они сделали отложенным очистку по одной простой причине: она автоматическая и если она будет включатся, когда ей вздумается, то она может слегка подвесить рантайм

что касается нашего варианта, то
а) я не согласен называть его GC вариантом (причины уже изложил выше)
б) пользователь сам решает когда вызывать delete stage75(); и этот вызов он спланирует так, чтобы с прикладной точки зрения это было наиболее выигрышно. классический пример: уровни в компьютерных играх: закончился уровень, почистили его и загрузили ресурсы нового уровня

что же касается обсуждаемой задачи



то тут
а) падения нагрузки не будет
б) если кто-то по дури захочет совершить такой трюк с деревом объектов на 450 мб))) то этот факт обязательно заметят, очень быстро найдут и устранят. обращаю внимание: это факт, а не баг!! это задача оптимизации работы программы, а не задача отладки

короче, вопросы скорости тут не критичны

Edd.Dragon, я 100% понял что вы имеете ввиду, но ваши логические комбинации из речевых конструкций скорее мотивированны получением удовольствия от концептуальных форм, чем от решения конкретной задачи, тогда как если сделать конкретную задачу критерием логики, тогда часть ваших конструкций теряет силу...

Edd.DragonОбъект не занимал ничей указатель.




второй объект занял указатель первого объекта

Edd.DragonВдумайтесь что есть объект, что он занимает, а что есть указатель на объект, и какое к нему отношение имеет сам объект? Никакого.

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

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




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

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


Edd.DragonУказатель имеет отношение к объекту (он на него указывает). А объект к указателю - не имеет. Не знает о нем ничего.

Сама тема возникла из-за того, что это так.
И тема создана, а как это исправить.
Вы мне как бы пытаетесь объяснить, что кусок металла весом 1 тонну не может сам улететь в космос, потому что есть гравитация. А я пришел сюда узнать как использовать ракетные двигатели, то есть как можно преодолеть ограничение.


Edd.DragonБолее того, при создании объекта никого указателя нет. Есть создание объекта в памяти. А потом уже в указатель записываем адрес на эту память.

Его нет в общем случае, но в нашей конкретной ситуации он есть!! и есть всегда!





Edd.DragonПри чем, ранее в этом указателе могло быть значение и факт того, что теперь в нем новое значение, еще не означает необходимость удалять прежний объект.

В общем случае да, но в нашем случае это 100% обозначает, что удалять надо, потому что начальное значение указателя всегда 0 и если оно не 0, значит там есть объект!!

Edd.DragonНе новому объекту решать, нужен еще старый кому-то или уже никому не нужен. Это бред.

Это не бред, а задача.)))

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


Edd.DragonИ не важно, что именно в вашей задачи именно сейчас этот бред пока что имеет некоторый смысл.

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

Edd.DragonЭто все-равно бред.

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

Edd.DragonА завтра еще и источник невероятных паранормальных явлений в вашем приложении.

А вы знали, что чисто статистически 99% событий, которых опасаются люди, не случаются вообще, а те опасные события, которые и случаются, то они часто оказываются примерно в 10 раз тусклее по опасности, чем рисовало воображение, а все подлинные катастрофы происходят тогда и оттуда, откуда никто никогда не ожидал даже принципиально!!

Edd.DragonЭто какое-то издевательство )))

Вам уже хочется меня ударить?? ;)
Я так-то хороший... могу и просто в сторонку отойти, если градус накаляется...)))

Anatoly MoskovskyКакая еще перегрузка шареда.
Смена объекта в смарт-указателе делается через функцию reset().

Хорошо, reset(), супер, отлично.
make_shared<>() круто, ништяк.

Но как мне эти штуки запаковать под капот, чтобы все работало по форме




тут хотя бы оператор равно появился - уже круто




как теперь можно спрятать этот make_shared, чтобы остался только = new A
надо class B менять или прирастить к shared_ptr::operator+()??

или может под мой случай какую-то свою легкую версию шареда написать??

Edd.DragonТак на кой же вы им даете прямой доступ к чертовым указателям внутри контейнера?

А как по вашему они должны юзать функции этих объектов-то??

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



Edd.DragonПочему мы только на "третий день" узнаем, что дело не в автоподтирании, а в том, что у вас какие-то проблемы с инкапсуляцией и вы не хотите видеть ее в общепринятом виде?


У меня нет проблем с инкапсуляцией!! все с ней отлично!! задача про автоподтирание

более того, инкапсуляции-то нет, ведь указатель не хранится в объекте, а хранится глобально!! мы тут ничего не инкапсулируем. вся "инкапсуляция" происходит внутри функции b()!!

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

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

MasterZivА если это возможно, то всё, знаешь ли, очень просто -- сокрой все методы создания и удаления объекта в классе, сделай что-то типа фабрики, но ещё и с поддержкой удаления, -- и всё, делов-то.

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

Немного не понял идею про фабрику...
Просто вот то решение, которое сейчас предложили на шарах, я разложил его на две части: сам класс class A + управляющая функция a(), которая при первом обращении к себе создает объекты, а при последующих просто возвращает уже созданный, при этом она дает доступ ко всем методам и дата-мемберам a()->draw(), a()->title = "Hello";, позволяет убивать себя как обычно delete a(), которая при этом убивает ещё и всех своих присоединенных чилдренов a()->addChild(b()) c()->setParent(a()) все это круто работает

и теперь встала задача развить функционал чтобы можно было эти горячие объекты ещё и заменять новыми объектами, без нарушения участия этого объекта в других частях программы, чтобы можно было в любой части программы подменить b() = a() или что то же самое b() = new A, при этом все остальные части программы можно не трогать

на самом деле все уже практически готово, потому что есть функционал b().reset(new A) или b().reset(a()) и остался совсем малюсенький шажок как это превратить в b() = new A ака b() = a();

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

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

MasterZivТы хочеш скрестить ужа с дикообразом ? И что получится ?
И главное зачем ?

GC я не строю. Это глупо. А задачу на лету потереть старый объект и на его место в памяти прошить новый объект это вполне реально. По сути дела, я спрятал все действия по работе с памятью за один интерфейс, которым в данном случае является функция аксессор a()

то есть во всем коде, пользователь пишет как ему надо и использует функцию a(), а какие именно объекты, какие именно участки памяти там используются это управляется в другом месте, например, в контроллерах событий a() = b()

Edd.DragonА ключевое слово new кто пишет?

Функция аксессор при первом обращении. При любом первом обращении!!

пользователь пишет



удалил первую строчку




в общем, кто первый вызвал, тот и папа

MasterZivЕсли ты законтролируешь указатели на объекты в виде умных указателей, у тебя встанет проблема контролирования указателей на указатели (возможно, умные) на твои объекты.

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




MasterZivТебе для твоей задачи надо просто уйти от интерфейса в виде




и всё будет проще.
можно использовать хэндлы, номера объектов, имена объектов (на самом деле это всё одно и то же), что хочеш. И тебе сразу станет проще.

А у нас такого и нет вообще. Это я просто для примера тут приводил.

У нас вообще нет объектов в пользовательской части, только функции. Объекты только данных: строки, числа, картинки, кисти и т.п., т.е. вся расходка. Все остальное существует только в виде функций, т.е. все спрятано под капот.

Глобальные номерки это все уже есть и все работает. То есть у каждого аксессора уже гарантировано есть a()->gloId, a()->className и другая мета, но я пока не придумал как это можно заюзать для решения задачи, обсуждаемой в этой ветке.

MasterZivТебе нужно чтобы при перезаписи старое удалялось ? Напрямую реализуй эту концепцию в своём классе, сделай там слоты для объектов, и дай пользователям возможность в слотах создавать и удалять объекты. НЕ ДАВАЯ им доступ к объектам напрямую,
инкапсулируя все операции с этими объектами по слотам.

Немного не понял...

Любой объект уже можно БЕЗОПАСНО удалить через delete a(); а любой последующий вызов a() создаст новый объект. Сейчас задача про a(1) = a(2), чтобы а(1) при этом потерся из памяти и записал на свое место a(2), чтобы они в итоге оба указывали на одно и то же.

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

ok