ДохтаРОбьявите статическую переменную в struct catcher в которой храните адрес globalStore который вернул
первый вызов new.


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

maytonLumix, ты лучше не словами. А копи-пасти выхлоп компиллятора. Те кому надо - разберуться.

Я конечно могу, но я думал на этом форуме кидать дамп это моветон...

Там реально ISO forbid void* data member. и больше ничего интересного
а кроме того, приведенный пример является полным, то есть это не кусок из рабочего когда, весь *.cpp файл целиком. Каждый может вырезать его, вставить в пустой файл, скомпилить G++ ом и все увидеть самому.

ДохтаРА почему static void* autoKill = 0 ?

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

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

может есть какой-нибудь способ как положить
новый объект на место старого, а если старого
ещё нет, то создать это место?






ДохтаР3 А этого я вобще не понял
operator new this;
Откуда this ?
вы находитесь в статической функции ей фиолетов this.


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

ДохтаРНе нужно ничего преразмещать ::new () должен вызываться 1 раз,
на входе в оператор вставьте проверку if (autoKill !=NULL ) throw 1 ;
и посмотрите докуда доработает ваша программа.

Она упадет на строчке globalStore = (user8b*) new user4b(6);



Я сделал как вы сказали + убрал ссылку



И у меня теперь все прекрасно компилится и все отлично работает, ничего не падает.
Результат работы программы 65.
6 это от user4b, а 5 от старой user8b
То есть new даже без ссылки отлично перезаписывает на это же самое место!!

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




но на это у меня сегодня мозгов уже не хватит))) надо на свежую голову будет подумать

ДохтаР, спасиииибо!!!

Anatoly MoskovskyLumix,

Люди развлекаются между прочим.

На посты типа "у меня дробовик есть" я внимание особо не обращаю))))
мой вопрос, с которым я сюда обратился РЕШЕН!!

MasterZivЧтобы сделать ЧТО ? Ещё раз объясни... Автоматом удалять объекты?

Удалить объект, который хранится по адресу в ссылке, в которую я хочу создать новый объект




void* operator new(size_t size)
{
// как тут получить доступ к перезаписываемому
// указателю-то??

Никак. Нет тут к нему доступа.

ок, понял

void operator delete(void* obj)
{
::operator delete(obj);

// через что тут обнулять-то??

Не через что. Комментарии ниже.

ок, понял

// ведь операция удаления в самом
// общем виде не обязывает программу
// юзать указатель вообще...

Это я не понял.

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




вот тут у нас два объекта
они одного типа, но они разные
первый a = 5, второй a = 6
указатель у них один
возникает вопрос как из а = 6 можно узнать, что он перезаписал чей-то чужой указатель и соотв. убить тот объект, который был в том указателе

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


MasterZivГлавное:
Пойми одну простую вещь: В С++ создание объекта состоит из выделения объекту памяти и инициализации в ней объекта.


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


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

для простоты пользователей мы рассматриваем вариант только кучных объектов через new / delete
никаких стеков


MasterZivУничтожение объекта также двухстадийное и тоже независима деинициализация от размещения объекта в памяти.

сложность в том, как организовать связь процессов удаления/создания с процессами контроля управляющих структур (указателей)

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

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

конкретно эта тема про засовывание в аксессор верхнего уровня нового объекта-предка




MasterZivЧто ты должен был бы понять из вышенаписанного относительно твоих "хотелок":
что ни operator new/delete, ни конструктор с деструктором никак не связаны с организацией автоматического удаления объектов.
Они не могут это реализовать вследствии того, как организована модель памяти в С++ -программе.

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

MasterZivЭто (garbage collector) должен реализовать какой-то другой класс, внешний по отношению к твоему. И логично это делать сразу для нескольких классов, а не для одного.

тема не про GC

maytonКак мы можем это знать в рамках С++ ?

Блин, вообще-то это я с этим вопросом сюда пришел. ))) Если бы я знал, темы бы не было...


maytonКто тебя схватит за руку или запретит это сделать?

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

Anatoly MoskovskyДанная задача решается только через shared_ptr.

я сделал как вы порекомендовали
все работает!!

только почему-то shared не хочет принимать через равно внутренний объект, переданный ему через указатель... это чё мне перегрузку шареда надо мутить, да??

Edd.DragonПроще, если не запутать и их. Вы как раз в этом направлении и двигаетесь упорно ))

я наоборот хочу избавить их от всяких концепций shared pointer, о том, что создаются копии на границах вызовов функций и прочих вещей. Пользователи для работы с объектами пользуются только функциями, где любое первое использование создает объект b()->draw() и с new вообще никто не соприкасается ни разу

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

Edd.DragonБыл объект. Его дропнули переприсвоением. Возникает желание удалить. Неявно. Разве не простейший GC?

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


Edd.DragonНу и с каких делов объект-предок может решать, можно ли удалять своего коллегу?

С очень простых делов: он занял его указатель!! Критерий четко задан. Это и есть условие задачи.




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

Имхо в этом абзаце эмоции... Задача-то конкретная. Зачем "мировые" проблемы тут обсуждать?))))