Собственно интересует модель поведения. Есть класс который хип онли. Производный класс обладающий так же конструктором и деструктором, он будет наполовину (та часть что как бы оверхед родителю) стековым и наполовину (та часть от которой наследуемся) динамическим?   
Иными словами, есть ли необходимость дописывать свойства хип онли (прятать конструкторы и деструктор) классу который наследуется от хип оноли?

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

BearFear, что за бред? Где ты таких терминов нахватался? Объект размещается полностью в куче, только когда ты делаешь new ClassName. Если ты создал локальный объект, то в стеке размещается как минимум указатель на область в куче.

Классы, которые хранят данные в куче, ничем не отличаются от тех, что хранят данные в себе.

В состоянии экстаза я вместо вопроса выдал нелепое предположение. Сорюшки!


Уопрос: как выглядит наследование от хипонли с тем условием что и дочерний класс так же должен быть хипонли?

Если ClassB у тебя наследник, то делаешь в нем свой статический create_instance и все.

Хм Работает. Ща... не-ну я же зачем то задал вопрос видимо я просто потерял нить. Черт возьми, не может быть все так просто. Мне надо как то оправдать сложность вопроса, что бы не прослыть глупцом.

Не ищи сложностей, там где их нет.

Черт возьми, я примерно недели две назад столкнулся с проблемой, записал ее на бумаге. Понадеялся на свою память и только счас понял что я забыл ваще о чем была речь. Бумажка потерялась в серых рабочих буднях не относящихся к С++. Написал вопрос на автомате, сгенерировав тему за 0,0036 секунды. Видать старею мозг окисляется у меня с каждым днем все больше.

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

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

Проблема возникла в том, что наследник не имел возможности создаваться хипонли лишь будучи наследником суперкласса. Вот собственно и вопрос: как сделать наследника хипонли без дописывания методов.
На чистом языке это сделать нереально. Тут же ниже мелким шрифтом написал пометку, что можно использовать препроцессор. Наверно это будет самым подходящим методом экономящим время. Достаточно написать в теле класса какую то штуку на подобии HEAPONLY_HEADER(class_name), который подставит все необходимые и похожие между собой (для хипонли классов). Возможность определения конструкторов и деструктора так же можно заложить в разнообразии препроцессорных дефайнов    не, ну а чо, если есть препроцессор, почему бы его не использовать? Сори за ложную тревогу.

Добавлено через 49 секунд
А хотя ваще не... услышать мнение народа на этот счет тоже интересно. Так что все кто готов протестовать, буду рад услышать. Возможно и переключимся на инновации.

BearFear,    

mes, я с тобой согласен.
BearFear, ты сэкономишь уйму времени, если вместо объяснения "что тебе нужно" ты попытаешься объяснить "зачем это нужно".

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

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

BearFear, Посмотри "Наиболее эффективное использование C++" Мейерса, правило 27. "В зависимости от ситуации требуйте или запрещайте размещать объекты в куче". Там и вопрос наследования подобных классов рассматривается, правда не уверен, что в той плоскости, что тебе нужна.
 

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

Я как-то не вижу случаев, для чего это нужно. Конечно, это скорее всего нужно, в каких-то очень редких ситуациях, для конкретных классов. Но не думаю, что проблема написать продуцирующую функцию для конкретного одного-двух классов.


Есть всякие unique_ptr, shared_ptr и тд. Зачем вообще использовать delete? Опять же случаи могут и быть, но на столько редкие, что я никогда с ними не сталкивался.

Ну вот например, такая ситуация. У нас есть некий профиль предоставляющий определенные возможности. Этот профиль - класс. Реализация профиля - это когда есть всяческие механизмы и подчиненные классы. Иными словами, класс профиля предоставляет нам возможности, а реализация возможностей состоит из всяких там классов, структур, методов класса профиля (ну пусть это будет ГЛАВНЫЙ класс профиля, (специально не пишу интерфейс, дабы не вертелись в голове паттерны)) и прочего. Когда мы просим метод профиля что то сделать, метод профиля создает динамический объект. Но, этот же класс позволяет передавать подчиненные объекты между собой. А следовательно, любопытный кодер может по неаккуратности взять и передать по указателю стековый объект. При удалении объекта владеющего подчиненным удалится стековый объект через delete. Если использовать метод объекта удаляющий его, то все более безопасно. Разновидность таких объектов может быть бесконечной, создавать копипастой методы для хипонли - противоООП методика.

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