Чем может быть чревато создание в классе адреса на другой класс

@Divergence · Регистрация: 19.06.2013

Author24 — интернет-сервис помощи студентам

Всем привет!
Я решил не заморачиваться с наследованием, так как у меня каждый класс использует только свои узкоспециализированные функции. А вот некоторые данные из класса все равно таскать приходится.
Таким образом, у меня возникла вот такая, можно сказать, иерархия:

C++

class Object //Хранит в себе всю информацию о любом объекте
{
public:
float o1;
float o2;
float o3;
Object() //Конструктор
{
o1 = 1;
o2 = 2;
o3 = 3;
}
~Object(){} //Деструктор
void ObjectFunc1(){} //Функция 1
void ObjectFunc2(){} //Функция 2
};
 
class Paint //Клас Paint не наследует класс Object, тем не менее имеет внутри себя один экземпляр класса Object
{
public:
Object* MyObject; //Адрес экземпляра класса Object
Paint(Object* fObject) //Конструктор
{
MyObject = fObject; //Копирование в переменную класса Paint адреса уже существующего экземпляра Object
}
~Paint(){} //Деструктор
void PaintFunc1(){} //Функции-члены Paint
void PaintFunc2(){} 
};
 
void WinMain()
{
Object *MyObject = new Object;
Paint   *MyPaint   = new Paint(MyObject);
 
//Используем Paint как хотим
 
delete Object;
delete Paint1;
}

Вот так у меня это реализовано.
Вопрос в том, есть ли в такой реализации подводные камни, если есть, то какие??
Буду благодарен за любые предупреждения и мысли по этому поводу.
Лично мне кажется, что никакой опасности нет, тем не менее чутье ноет о том, что здесь не совсем все так просто как кажется...

@Nekto · 09.06.2014, 02:17

Голые указатели всегда опасны.

@Divergence · 09.06.2014, 02:25 **[ТС]**

У меня структура даже сложнее чем я указал:
есть еще класс stage, который имеет в себе Paint и похожие по структуре на Paint классы и манипулирует ими тем же способом. Я планировал сделать ЕЩЕ класс, который будет манипулировать stage'ами, но у меня полезли какие-то настолько странные ошибки, что я отказался от идеи так глубоко залезать по классам и сделал просто функцию.
Тем не менее такая сложная иерархия классов осталась (получается, что один класс имеет доступ к экземплярам двух классов, которые еще и создан один из другого).

IGPIGP · 09.06.2014, 03:00

Divergence, использование объектов классов или указателей на объекты классов в качестве полей классов это нормально. Если говорить об указателях, то это чуть более трудоёмко чем просто использовать сам объект. Разница почти та же, что и при использовании переменной указателя на стеке, но тяжелее то, что конструкторов не один и везде нужно побеспокоиться о инициализации указателя. То есть нужно выделить память, чем-то заполнить, а в деструкторе удалить.
В Вашем конструкторе копируется указатель и Вы не можете знать указывает он на что-то разумное или нет. Обычно в таких случаях делают иначе. Но сначала нужно написать конструктор без параметров и или закрыть его (тогда он может быть пустой) или выделить в нём память под объект и заселить её объектом по умолчанию. Закрывать - прём узкий. Это значит, что контейнеры STL использовать не выйдет, например.
Написав открытые конструкторы Вы будете уверены, что как бы не создавался экземпляр, он будет инициализирован. А в конструкторе копирования тоже нужно бы выделить память и скопировать в неё объект из оригинала почленно. В деструкторе удалить. Тут лучше ничего не делать руками.

@Divergence · 09.06.2014, 03:16 **[ТС]**

Сообщение от IGPIGP

Divergence, использование объектов классов или указателей на объекты классов в качестве полей классов это нормально. Если говорить об указателях, то это чуть более трудоёмко чем просто использовать сам объект. Разница почти та же, что и при использовании переменной указателя на стеке, но тяжелее то, что конструкторов не один и везде нужно побеспокоиться о инициализации указателя. То есть нужно выделить память, чем-то заполнить, а в деструкторе удалить.
В Вашем конструкторе копируется указатель и Вы не можете знать указывает он на что-то разумное или нет. Обычно в таких случаях делают иначе. Но сначала нужно написать конструктор без параметров и или закрыть его (тогда он может быть пустой) или выделить в нём память под объект и заселить её объектом по умолчанию. Закрывать - прём узкий. Это значит, что контейнеры STL использовать не выйдет, например.
Написав открытые конструкторы Вы будете уверены, что как бы не создавался экземпляр, он будет инициализирован. А в конструкторе копирования тоже нужно бы выделить память и скопировать в неё объект из оригинала почленно. В деструкторе удалить. Тут лучше ничего не делать руками.

IGPIGP, спасибо за ответ!
Если честно, я не очень понимаю эти опасения по поводу того, что указатель может не указывать на существующую область памяти... у меня в коде сначала выделяется память, только затем в новый класс передается указатель. В случае такого грамотного подхода (когда ничего не забыто) опасности никакой нет?
Или все же могут быть косяки?
Например, я смутно предполагаю ситуацию, что в какой-то момент вызовется деструктор, который освободит память, на которую у меня несколько указателей по определению... Соответственно, несколько указателей будут указывать на пустоту. Однако, логика программы такова, что жизнь одного класса без другого просто не имеет смысла, поэтому уничтожаться они будут строго один за другим до самого конца. Остаются ли какие-то опасности при такой ситуации?

@Nekto · 09.06.2014, 03:20

Сообщение от Divergence

IGPIGP, спасибо за ответ!
Если честно, я не очень понимаю эти опасения по поводу того, что указатель может не указывать на существующую область памяти... у меня в коде сначала выделяется память, только затем в новый класс передается указатель. В случае такого грамотного подхода (когда ничего не забыто) опасности никакой нет?
Или все же могут быть косяки?
Например, я смутно предполагаю ситуацию, что в какой-то момент вызовется деструктор, который освободит память, на которую у меня несколько указателей по определению... Соответственно, несколько указателей будут указывать на пустоту. Однако, логика программы такова, что жизнь одного класса без другого просто не имеет смысла, поэтому уничтожаться они будут строго один за другим до самого конца. Остаются ли какие-то опасности при такой ситуации?

Зачем тогда создавать объект снаружи и передавать указатель на него? Почему бы не создать его внутри?

IGPIGP · 09.06.2014, 03:22

Сообщение от Divergence

В случае такого грамотного подхода (когда ничего не забыто) опасности никакой нет?

В случае такого грамотного подхода, само понятие опасности теряет смысл.

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

@Divergence · 09.06.2014, 03:30 **[ТС]**

Сообщение от Nekto

Зачем тогда создавать объект снаружи и передавать указатель на него? Почему бы не создать его внутри?

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

Добавлено через 5 минут

Сообщение от IGPIGP

А что мешает написать конструктор по умолчанию, конструктор копии, деструктор и перегрузить оператор присваивания?

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

IGPIGP · 09.06.2014, 03:35

Сообщение от Nekto

Зачем тогда создавать объект снаружи и передавать указатель на него? Почему бы не создать его внутри?

Конечно!

Сообщение от IGPIGP

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

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

Jupiter · 09.06.2014, 12:21

Сообщение от Divergence

Вопрос в том, есть ли в такой реализации подводные камни, если есть, то какие??

C++

1	Paint paint(0);

Tulosba · 09.06.2014, 14:07

Divergence, удалять объекты надо в порядке обратном их созданию. Т.е. сначала MyPaint, потом MyObject. А вообще, см. что такое "умные" указатели.

Сообщение от Jupiter

C++

1	Paint paint(0);

По приведенному ТС коду, проблемы с нулевым указателем нет.

Jupiter · 09.06.2014, 14:33

Не по теме:

Сообщение от Tulosba

По приведенному ТС коду, проблемы с нулевым указателем нет.

додо, конечно же у ТС все методы пустые и просто так хранится указатель

Tulosba · 09.06.2014, 15:27

Jupiter, додомывать можно сколько угодно. Может у него там и if'ами всё обвешано с проверкой на нуль. Но чего не показано, того не показано.

Jupiter · 09.06.2014, 15:34

Не по теме:

Сообщение от Tulosba

сколько угодно

Сообщение от Tulosba

нельзя идти на поводу у ТС. Надо жесткой хваткой взять его и сказать: "что же ты делаешь! Так нельзя.Потому что: раз, два и три".

занавес...

Tulosba · 09.06.2014, 15:38

Jupiter, не вижу связи. Одно дело, видеть кривой код и критиковать его. И совсем другое - критиковать по результатам своих фантазий.

@Divergence · 09.06.2014, 23:33 **[ТС]**

Ребят, а что такое ТС код?

Сообщение от Jupiter

нельзя идти на поводу у ТС

???

Сообщение от Jupiter

Надо жесткой хваткой взять его и сказать: "что же ты делаешь! Так нельзя.Потому что: раз, два и три

Кого его? оО

@Nekto · 09.06.2014, 23:36

Сообщение от Divergence

Ребят, а что такое ТС код?

С подключением к интернету. ТС = топикстартер.

@Divergence · 09.06.2014, 23:53 **[ТС]**

Сообщение от Nekto

С подключением к интернету. ТС = топикстартер.

Сообщение от Divergence

Надо жесткой хваткой взять его и сказать: "что же ты делаешь! Так нельзя.Потому что: раз, два и три

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

Добавлено через 13 минут

Сообщение от Divergence

Зачем тогда создавать объект снаружи и передавать указатель на него? Почему бы не создать его внутри?

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

@Nekto · 10.06.2014, 00:44

Сообщение от Divergence

Нужно работать с объектами других классов только внутри самого класса.

Для этого придумали умные указатели. std::shared_ptr, думаю, подойдет для данного случая.

@Divergence · 10.06.2014, 01:38 **[ТС]**

Сообщение от Nekto

Для этого придумали умные указатели. std::shared_ptr, думаю, подойдет для данного случая.

Спасибо! Почитаю об этом в ближайшее время!)

@Divergence 7 / 7 / 2 Регистрация: 19.06.2013 Сообщений: 174
	09.06.2014, 23:53 [ТС]	18
	Сообщение от Nekto С подключением к интернету. ТС = топикстартер. Сообщение от Divergence Надо жесткой хваткой взять его и сказать: "что же ты делаешь! Так нельзя.Потому что: раз, два и три Пока что я увидел опасность только в кодере, который может ошибиться. Другие аргументы меня не убедили. Как я понял, народ настаивает на создании еще одного пустого конструктора? А вот зачем сюда нужна перегрузка операторов - вот совсем не понял. Добавлено через 13 минут Сообщение от Divergence Зачем тогда создавать объект снаружи и передавать указатель на него? Почему бы не создать его внутри? Вы были абсолютно правы. Я сейчас собрал простенький проект с тестовыми классами (чтобы не морочиться с большим кол-вом кода). Если ссылку на один и тот же класс используют два класса (а у меня именно такая ситуация и назревала), то деструктор выкидывает в ошибку, так как я пытаюсь удалить пустоту. Вот и ответ на мой вопрос... нельзя передавать в класс просто ссылки на классы (особенно если они инициализированы в динамической памяти). Нужно работать с объектами других классов только внутри самого класса. 0

@Nekto 347 / 292 / 37 Регистрация: 23.03.2012 Сообщений: 838
	09.06.2014, 02:17	2
	Голые указатели всегда опасны. 0

@Divergence 7 / 7 / 2 Регистрация: 19.06.2013 Сообщений: 174
	09.06.2014, 02:25 [ТС]	3
	У меня структура даже сложнее чем я указал: есть еще класс stage, который имеет в себе Paint и похожие по структуре на Paint классы и манипулирует ими тем же способом. Я планировал сделать ЕЩЕ класс, который будет манипулировать stage'ами, но у меня полезли какие-то настолько странные ошибки, что я отказался от идеи так глубоко залезать по классам и сделал просто функцию. Тем не менее такая сложная иерархия классов осталась (получается, что один класс имеет доступ к экземплярам двух классов, которые еще и создан один из другого). 0

IGPIGP Комп_Оратор) $Эксперт по математике/физике$ 8950 / 4704 / 629 Регистрация: 04.12.2011 Сообщений: 13,999 Записей в блоге: 16
	09.06.2014, 03:00	4
	Divergence, использование объектов классов или указателей на объекты классов в качестве полей классов это нормально. Если говорить об указателях, то это чуть более трудоёмко чем просто использовать сам объект. Разница почти та же, что и при использовании переменной указателя на стеке, но тяжелее то, что конструкторов не один и везде нужно побеспокоиться о инициализации указателя. То есть нужно выделить память, чем-то заполнить, а в деструкторе удалить. В Вашем конструкторе копируется указатель и Вы не можете знать указывает он на что-то разумное или нет. Обычно в таких случаях делают иначе. Но сначала нужно написать конструктор без параметров и или закрыть его (тогда он может быть пустой) или выделить в нём память под объект и заселить её объектом по умолчанию. Закрывать - прём узкий. Это значит, что контейнеры STL использовать не выйдет, например. Написав открытые конструкторы Вы будете уверены, что как бы не создавался экземпляр, он будет инициализирован. А в конструкторе копирования тоже нужно бы выделить память и скопировать в неё объект из оригинала почленно. В деструкторе удалить. Тут лучше ничего не делать руками. 1

@Divergence 7 / 7 / 2 Регистрация: 19.06.2013 Сообщений: 174
	09.06.2014, 03:16 [ТС]	5
	Сообщение от IGPIGP Divergence, использование объектов классов или указателей на объекты классов в качестве полей классов это нормально. Если говорить об указателях, то это чуть более трудоёмко чем просто использовать сам объект. Разница почти та же, что и при использовании переменной указателя на стеке, но тяжелее то, что конструкторов не один и везде нужно побеспокоиться о инициализации указателя. То есть нужно выделить память, чем-то заполнить, а в деструкторе удалить. В Вашем конструкторе копируется указатель и Вы не можете знать указывает он на что-то разумное или нет. Обычно в таких случаях делают иначе. Но сначала нужно написать конструктор без параметров и или закрыть его (тогда он может быть пустой) или выделить в нём память под объект и заселить её объектом по умолчанию. Закрывать - прём узкий. Это значит, что контейнеры STL использовать не выйдет, например. Написав открытые конструкторы Вы будете уверены, что как бы не создавался экземпляр, он будет инициализирован. А в конструкторе копирования тоже нужно бы выделить память и скопировать в неё объект из оригинала почленно. В деструкторе удалить. Тут лучше ничего не делать руками. IGPIGP, спасибо за ответ! Если честно, я не очень понимаю эти опасения по поводу того, что указатель может не указывать на существующую область памяти... у меня в коде сначала выделяется память, только затем в новый класс передается указатель. В случае такого грамотного подхода (когда ничего не забыто) опасности никакой нет? Или все же могут быть косяки? Например, я смутно предполагаю ситуацию, что в какой-то момент вызовется деструктор, который освободит память, на которую у меня несколько указателей по определению... Соответственно, несколько указателей будут указывать на пустоту. Однако, логика программы такова, что жизнь одного класса без другого просто не имеет смысла, поэтому уничтожаться они будут строго один за другим до самого конца. Остаются ли какие-то опасности при такой ситуации? 0

@Nekto 347 / 292 / 37 Регистрация: 23.03.2012 Сообщений: 838
	09.06.2014, 03:20	6
	Сообщение было отмечено Divergence как решение Решение Сообщение от Divergence IGPIGP, спасибо за ответ! Если честно, я не очень понимаю эти опасения по поводу того, что указатель может не указывать на существующую область памяти... у меня в коде сначала выделяется память, только затем в новый класс передается указатель. В случае такого грамотного подхода (когда ничего не забыто) опасности никакой нет? Или все же могут быть косяки? Например, я смутно предполагаю ситуацию, что в какой-то момент вызовется деструктор, который освободит память, на которую у меня несколько указателей по определению... Соответственно, несколько указателей будут указывать на пустоту. Однако, логика программы такова, что жизнь одного класса без другого просто не имеет смысла, поэтому уничтожаться они будут строго один за другим до самого конца. Остаются ли какие-то опасности при такой ситуации? Зачем тогда создавать объект снаружи и передавать указатель на него? Почему бы не создать его внутри? 1

IGPIGP Комп_Оратор) $Эксперт по математике/физике$ 8950 / 4704 / 629 Регистрация: 04.12.2011 Сообщений: 13,999 Записей в блоге: 16
	09.06.2014, 03:22	7
	Сообщение от Divergence В случае такого грамотного подхода (когда ничего не забыто) опасности никакой нет? В случае такого грамотного подхода, само понятие опасности теряет смысл. Какая может быть опасность для человека, которого не испугать? А что мешает написать конструктор по умолчанию, конструктор копии, деструктор и перегрузить оператор присваивания? 0

@Divergence 7 / 7 / 2 Регистрация: 19.06.2013 Сообщений: 174
	09.06.2014, 03:30 [ТС]	8
	Сообщение от Nekto Зачем тогда создавать объект снаружи и передавать указатель на него? Почему бы не создать его внутри? Спасибо за идею! Действительно, я подумаю об этом. Небольшие трудности создает только то, что в дальнейшем, мне может потребоваться один класс отдельно от другого для каких-то еще не придуманных сейчас целей. Это удерживает. Но скорее всего я последую совету Добавлено через 5 минут Сообщение от IGPIGP А что мешает написать конструктор по умолчанию, конструктор копии, деструктор и перегрузить оператор присваивания? Просто не могу заставить себя делать что-то сложное, когда можно сделать просто. Я сделал просто и понятно для себя, без лишних наворотов. Если бы я точно понимал какие плюсы мне даст вся эта перегрузка и куча конструкторов, и я бы эти плюсы посчитал существенными, то конечно сделал бы так. Именно потому, я и написал вопрос на форуме: я сделал просто, хотя обычно люди делают сложно, и причин для такой сложности я не увидел. Вот и хочу послушать аргументы в пользу сложного подхода. Но пока, на такую сложную модель переходить я не переубедился 0

IGPIGP Комп_Оратор) $Эксперт по математике/физике$ 8950 / 4704 / 629 Регистрация: 04.12.2011 Сообщений: 13,999 Записей в блоге: 16
	09.06.2014, 03:35	9
	Сообщение от Nekto Зачем тогда создавать объект снаружи и передавать указатель на него? Почему бы не создать его внутри? Конечно! Сообщение от IGPIGP сначала нужно написать конструктор без параметров и ... выделить в нём память под объект и заселить её объектом по умолчанию. Ведь при попытке объявить такой объект как сейчас на стеке нужно будет каждый раз инициализировать его руками. А заполнить вектор такими объектами? Лучше пусть это делает конструктор, а прямой доступ к указателю снаружи и закрыть можно бы. 0

Jupiter
	09.06.2014, 14:33 #12
	Не по теме: Сообщение от Tulosba По приведенному ТС коду, проблемы с нулевым указателем нет. додо, конечно же у ТС все методы пустые и просто так хранится указатель 0

Tulosba :) 4773 / 3267 / 497 Регистрация: 19.02.2013 Сообщений: 9,046
	09.06.2014, 15:27	13
	Jupiter, додомывать можно сколько угодно. Может у него там и if'ами всё обвешано с проверкой на нуль. Но чего не показано, того не показано. 0

Jupiter
	09.06.2014, 15:34 #14
	Не по теме: Сообщение от Tulosba сколько угодно Сообщение от Tulosba нельзя идти на поводу у ТС. Надо жесткой хваткой взять его и сказать: "что же ты делаешь! Так нельзя.Потому что: раз, два и три". занавес... 0

Tulosba :) 4773 / 3267 / 497 Регистрация: 19.02.2013 Сообщений: 9,046
	09.06.2014, 15:38	15
	Jupiter, не вижу связи. Одно дело, видеть кривой код и критиковать его. И совсем другое - критиковать по результатам своих фантазий. 0

@Divergence 7 / 7 / 2 Регистрация: 19.06.2013 Сообщений: 174
	09.06.2014, 23:33 [ТС]	16
	Ребят, а что такое ТС код? Сообщение от Jupiter нельзя идти на поводу у ТС ??? Сообщение от Jupiter Надо жесткой хваткой взять его и сказать: "что же ты делаешь! Так нельзя.Потому что: раз, два и три Кого его? оО 0

@Nekto 347 / 292 / 37 Регистрация: 23.03.2012 Сообщений: 838
	09.06.2014, 23:36	17
	Сообщение от Divergence Ребят, а что такое ТС код? С подключением к интернету. ТС = топикстартер. 0

@Nekto 347 / 292 / 37 Регистрация: 23.03.2012 Сообщений: 838
	10.06.2014, 00:44	19
	Сообщение от Divergence Нужно работать с объектами других классов только внутри самого класса. Для этого придумали умные указатели. std::shared_ptr, думаю, подойдет для данного случая. 2

@Divergence 7 / 7 / 2 Регистрация: 19.06.2013 Сообщений: 174
	10.06.2014, 01:38 [ТС]	20
	Сообщение от Nekto Для этого придумали умные указатели. std::shared_ptr, думаю, подойдет для данного случая. Спасибо! Почитаю об этом в ближайшее время!) 0

Чем может быть чревато создание в классе адреса на другой класс

Решение