Вопрос вот в чем. Сам не знаю зачем мне это. Хотя цель примерно следующая: сохранить указашки на объекты и удалить если надо объекты вместе с хранителями их указателей. И вместо тысячи слов, быдлокод в студию!



Использование



Насколько опрометчиво использовать подобный подход?

Это сообщение отредактировал(а) BearFear - 25.9.2013, 17:38

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

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

Это сообщение отредактировал(а) BearFear - 25.9.2013, 19:40

пуристы сказали бы ещё, что Int и Сhar мало того, что не очень удачные названия переменных, но их и нужно delete перед завершением программы.

Скажу проще, что классический ООП фактически завершается после применения reinterpret_cast.
потому что в этом случае проще применять в owner указатели "void *" и без всякого шаблона, а дальше этот указатель приводить к желаемому для вас типу. (Или проще, такой код никому из сторонников объектно-ориентированной парадигмы не понравится, он методологически ближе к "выкрутасам" доброго старого С)

Этот код не для того что бы удовлетворить эстетические потребности читающего. Это формулировка и вы сами прекрасно знаете, на скорую руку писать мегасверхкрасивый код смысла нет, он затрется. А на счет реинтерпрета согласен. Это и смущает. Но по факту, 12 байт размер данного по приведенному указателю. Не по приведенному размер такой же. В диспатчере МС просмотрел выделяемые данные. Вроди бы как освобождается норм. За кадром использовал более весомые данные для хранения в шаблоноклассах. Это меня и смутило - неужели работает? Хотелось бы услышать более глубокие ответы, как от профессионалов. Теоретически я и сам не согласен с этим кодом по множеству пунктов и лишний раз напоминать об эстетике каких то моментов... ну господа, это не серьезно.

Добавлено через 7 минут и 6 секунд
akizelokro, в деструкторе owner (за пределами main - там при прочтении всего сообщения) есть delete тех некрасивых Int и Char. Ребят, если вам не интересно, то ну не пишите и не читайте совсем тогда. Вы и себе время сэкономите и мне не придется как то реагировать на заведомо "недочитанное" вами   

Прошу прощения, просто не ожидал.

ну, этот код и должен быть работоспособным кодом. До того момента, пока этот кусок кода не попадёт в посторонние руки и не начнутся возможные правки класса owner. Так что посоветовал бы поставить спецификатор "final".

Это сообщение отредактировал(а) akizelokro - 25.9.2013, 21:02

Высокомерие?   

Никакого высокомерия. Просто привык, что объекты лучше удалять на том же "уровне" кода, где они были созданы. Для наглядности.

Да. Это самый минимальный из минимального. Больше никаких пристроек. Вообще, хотел сделать некое подобие очищалки, для более безопасного вызова экцепшенов. В случае экцепшена опрашивается манагер цепи и он то уже зачищает все новые объекты. В общем самый важный и важнее всех важных вопросов данного топика - есть ли подводные камни именно у этого кода. Не гепотетически, не предполагая всевозможных других использований (не люблю гонку за полтергейстами), а именно то как вот есть. Сам принцип. А небезопасности везде хватает. По дурости как говорится можно и луже утонуть. чтож теперь, бегать за лужами и знаки ставить? Или того лучше дружиников заставить дежурить у луж?   

Вообще, у меня есть мой парсер, один экземпляр которого я заточил под С++. Он, делает забеги по коду, делает определенные выводы по типам и их использовании и снимает все RTTI в нужных местах. Они обособляются макросами. Но это уже другая история. Решил разнообразиться, вдруг найдется иной способ хранения разных типов в одном месте без последствий в виде утечки.

Это сообщение отредактировал(а) BearFear - 25.9.2013, 21:14

прочитал два раза, но не уверен что понял зачем все это. если цель в

то не проще ли что-нить вроде std::list<std::shared_ptr<boost::any>>>? причем без косяков в отношении типов, о которых сказал volatile. 

Шаред поинтер сработает в случае SEH? Интересно, где я был когда ввели такую возможность в буст?   
Если бы я спросил про АНАЛОГИ, может было бы и к месту. Программистов считают людьми, которые воспринимают все слишком буквально. В данных случаях очень много "неявностей" пришлось увидеть. Неизвестные кодеры которые якобы могут вмешаться в код. Предположение о поиске аналогов... Эх, или я не так выражаюсь или собеседники непонятливые.

Уважаемые, о том ЗАЧЕМ это нужно я уж как то сам разберусь. Тема ведь не - помогите разобраться зачем мне это и как это использовать?

Это сообщение отредактировал(а) BearFear - 25.9.2013, 22:10

точно так же, как и ~owner()
зачем вам SEH я не спрашиваю, т.к. это не моё дело и вопрос не об этом   


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

Вызвать ~owner из seh хандлера куда проще чем n деструкторов по неизвестным адресам. Поэтому я могу даже гарантировать, что ~owner будет вызван.
Ну смысл получается таким - после маин следует стековая процедура создающая синглтон-манагер, который отвечает за создание и очистку двусвязного списка. В используемом окружении все  кроме некоторых POD создается динамически. Это уже устоявшийся паттерн, который гарантирует динамическое созданиеотсутствие конструктора копирования и отсутствие ненужных операторов. Есть даже  макрос который сокращает путь создания. POD типы, или чаще это структуры, оборачиваются при динамическом создании. Разумеется, метод паттерна может включать код добавления СЕБЯ в список. Это будет рано 1-2 присваиваниям. Если seh - вызывается цепь деструкторов. Достаточно корневому объекту подать команду. Если не seh, то в стековой процедуре инита окружения вызывается та же цепь деструктуров. Но опять же, описаное выше как то изменит наличие ошибки в коде первого сообщения? Нет. Поэтомуя сразу и написал, что сам не знаю зачем оно мне. Что бы вопросов не было.

Это сообщение отредактировал(а) BearFear - 26.9.2013, 07:51

BearFear, просто попробуйте написать процедуру удаления вашей цепочки.
А мы посмотрим   

У нулевого звена (адрес которого и хранится в манагере) как и у других звеньев, есть метод delete_chain(). Он будет отвечать за удаление ОТ текущего звена до последнего элемента связи. За срок жизни программы, данная манипуляция будет проводиться 1 раз.


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

Организация подобного в виде массива накладно. Свести в один массив кучу указателей а потом еще и пытаться туда дописать... А такая штуковина не требует индексации, поэтому тут совершенно ненужен  учет количества. Все что смущает, это верность следующего утверждения: одинаково ли удалятся шаблонные объекты, если был вызван метод класса не зависящий от параметров шаблонного класса, который в свою очередь дернул деструктор внутри себя. Если это так, то ... то круто! Более навороченного варианта и не требуется.

Это сообщение отредактировал(а) BearFear - 26.9.2013, 12:06