Во первых ваш код не скомпилится - использовать просто owner в нем самом нельзя, т.к. owner это шаблонный класс, и должно быть как минимум owner<какой то тип>

Исли заменить все owner на owner<type>, то все соберется, но тут начнутся проблемы в другом месте. В том, где у вас reinterpret_cast<owner<int>*>. 

Проблема в том, что delete не только освобождает память (это он сделает правильно), но и вызывает деструктор. Если у вас в owner попадут не char/int, а классы со своими деструкторами, вы получите вызов не того деструктора

xvr, а повлияет ли тот факт, что в шаблонном классе хранится не данное, а типизированный указатель? Он же по идее должен быть лонг указателем грубо говоря? Я имею ввиду, что шаблонный овнер содержит не данное, поэтому тип параметризации становится неважным. Или я ошибаюсь?
Ведь шаблонный класс (и его часть - деструктор) отвечает ведь только за сам шаблонный объект. А шаблонный объект... стало быть при реинтерпретации будут указаны неверные размеры хранимого данного?
Тогда текущий вопрос имеет переформулировку. Влияет ли реинтерпретация типа шаблонного объекта на вызов деструктора встроенных в него полей (указателей на динамические данные)?

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

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

Вчера хотел вякнуть про удаление объектов и необходимость перегрузки delete().
Но я не особо лихой программер, и что там функция free будет делать и как всё это прописать получше.

Хотя там же опять загвоздка, что данные создаются не на том "уровне". На "том" уровне можно было бы поизвращаться ещё. А так проблемка. Хотя и там тоже некоторая проблемка (надо вспоминать, как в С выделение памяти работает и всё такое прочее)

Добавлено @ 13:14

Здесь вопрос возникает, насколько много не относящихся. Утверждение, что всё должно работать, просьба дезавуировать. БЫло написано, когда код до конца не дочитал и не предполагал, что объекты будут удаляться в деструкторе owner<>

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

Типизированный указатель, тип которого не соответствует реальному типу данных.

Да, но ведь как не крути, это всего лишь лонг. Типы отслеживаются только на стадии компиляции. За пределами компилятора можно лишь частично узнать тип, скорее всего без преобразований туда-сюда (я имею ввиду преобразования прямо в лоб, не динамик-касты). Следовательно, программе должно быть пофигу на что указывается лонг. Могут быть оверхеды, об их существовании ходят мифы, но я так и не понял есть ли они. Если они есть, то дело плохо. Но чаще я встречал инфу о том, что С++ один из немногих языков не имеющий оверхедов касающихся типов. Следовательно, имеется ряд объектов:
1 - объект владеющий элементом цепи
2 - элемент цепи владеющий данным
3 - данное

При удалении элемента цепи взаимодействуют 1>2 затем 2>3. То есть, связи между 1 и 3 нет, и объект 1 и не должен знать о том что содержит 2й. Единственное что может повлиять - если деструктор в памяти принимает аргумент при вызове, который как то указывает на тип, что в свою очередь влияет на размер удаляемого данного. Но по мне это не должно быть так. Ну я бы так не стал делать. Потому что в этом случае, неправильный вызов деструктора привел бы к плачевным последствиям. Это все балабольство конечно, мысли в слух.

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

У вас здесь может быть всё, что угодно.
Вы здесь говорите на разной терминологии.
Один в рамках чистого ООП, при котором код передаётся спокойно от одного к другому программисту (и пишется исходя из этого). И достаточно проблематично, кстати, написать неправильно код по высвобождению памяти для обьектов в принципе правильно оформленного двусвязного списка. Другой пишет код в стиле "выкрутасного" С в ООП парадигме и при этом запрашивает совета большого числа программистов, отрицая сам факт, что его код будут просматривать (и фактически применять другие программисты).
Наряду логический дискурс.
Что интересно. Можно было бы написать и так, если вспомнить, как же я всё-таки выделял память лет 10 назад для Сшных программ, и можно ли там правильно освобождать память, исходя только из одного указателя (или хэндлера на выделенный блок памяти, чтобы вне зависимости от размера объекта, память высвобождалась правильно). Вне зависимости от того, какой объект вы собираетесь подвести под перегруженный (должен быть перегруженный) delete().
Вообще сама задача нисколько не похожа на wrappers для указателей, в ней берутся уже неизвестно где (на уровень кода выше) объекты, предварительно построенные на предположении о том, что память для них выделена динамически (ладно, для чистоты эксперимента поверим) и сам класс (обрывок кода по сути) должен правильно удалить этот объект. Либо, в предположении автора, объекты могут удаляться неправильно, но автор сделает так, что последствия будут незначительны  

А можно для попытки изврата и привести примеры, где автор сделает так, что последствия усугубят "undefined behaivour" настолько, что слетит система.

Это сообщение отредактировал(а) akizelokro - 26.9.2013, 19:16

volatile, Из ничего всего не бывает. Если для вас букв слишком много, вас никто не заставляет их читать. Впрочем вы можете и не доводить до конца формулировку вашего кода. К чему много букв кода, когда можно просто писать un in v = ; И если есть какие то детальные понимания у вас, то изложите. Из вашей немногословности, лично я мало что могу понять, все выглядит как простые выкрики из толпы: ".... бред..... фигня.... не получится....". Ну если вы владеете истиной, откройте ее для меня, я за это скажу много раз спасибо.

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

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

Так в С++ делать НЕЛЬЗЯ!
(у вас если отбростить кучу застилающего хлама, делается именно так)  

Вы это понимаете?

Такой большой массив за один раз не получится выделить. В вашем коде, переназначается данное указателя. У меня такого не происходит. А вот то что может удалиться значение ПОСЛЕДНЕГО каста... в это я еще поверю. Я и сам знаю что такое могло произойти. В общем ладно, оставлю обсуждение до понедельника, там может (если руки дойдут) на асме поковыряюсь, может вставками на асме добью это дело. Просто наследование и удаление через суперкласс с виртуальным деструктором не очень хочется. Не все классы получится наследовать. И сам факт виртуального деструктора, там же как то поиск производится, на это уходит времени куда больше, чем при прямом обращении к не виртуальному деструктору.

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

BearFear,  храните полиморфный deleter (например void (*deleter)(void *)) в паре с указателем и будет вам счастье  
для определения делетера используется шаблон. подобное решение можно применять всегда , когда на месте применения важен не тип, но действие..  подробнее поиском по "type erasure" 

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

Это сообщение отредактировал(а) BearFear - 27.9.2013, 08:37

это избыточное решение..

Добавлено @ 08:38
вот тут пример поведния : http://forum.vingrad.ru/forum/topic-326256...sure/index.html

Это сообщение отредактировал(а) mes - 27.9.2013, 08:38

mes, ДА! ООП в данном случае - это очень много действий вокруг и около!