Порядок создания и уничтожения динамических объектов в классе

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

0

NewEmbedder, это зависит от логики их (объектов) взаимодействия.

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

0

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

0

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

я сейчас понимаю происходящее так

Добавлено через 52 секунды
все объекты уничтожатся сами в нужном порядке

0

Алексей1153, Вы правы, есть и списки, там все реализуется само собой. Но есть и графические примитивы (здесь применяется Qt3), где одни примитивы встраиваются в другие.
Я понял Вашу идею с умными указателями. Остался вопрос с прямым и обратным порядком создания и уничтожения внутренних объектов, на сколько важно это требование, и есть ли ссылка на регламент.

0

NewEmbedder, в Qt:
объекты, производные от QObject, в конструктор могут получать указатель на владеющий ими объект (или позже - через setParent). Владельцы сами удалят свои объекты. А если объект удаляется по другой причине, владелец удалит его из своих списков

все остальные объекты - работают "согласно обычным правилам C++"

Покажи пример, с чем именно возник вопрос?

0

Пример показать не могу, проект доставшийся в наследство имеет более сотни файлов. Работает в разных городах на некотором числе рабочих мест под FreeBSD, на одном из которых был вылетел из программы. Было подозрение на диструкторы, и пока оно остается.
За советы спасибо.

0

NewEmbedder, так проект и не надо. Минимальный примерчик, где показана нужная архитектура

0

Сообщение от NewEmbedder Вопрос такой, требуется ли в диструкторе уничтожать объекты в порядке обратном по отношению к тому порядку, что был в конструкторе и насколько это важно?

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

обрати внимание: речь идет о захвате/особождении ресурсов.
а не о создании/уничтожении объектов.

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

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

0

hoggy, спасибо за разъяснения. Я понимаю так, что порядок создания или выделения памяти для данных-членов класса всегда соответствует порядку их объявления (декларирования) в заголовочном файле, и нам нельзя вмешаться в этот порядок как при создании объекта класса, так и при его уничтожении. Но мы все же можем в произвольном порядке создавать другие объекты внутри класса командой new, где для каждого из них есть только указатель, что будет храниться в одном из данных-членов. А уничтожаются объекты командой delete в диструкторе, и если один из объектов не был создан, то и не нужно выполнять соответствующую ему команду delete. Вопрос мой касался именно порядка создания и уничтожения этих объектов внутри класса. Похоже, что этот порядок не принципиален, главное не допустить уничтожение тех объектов в классе, что не были созданы, и как это технически сделать мне стало уже понятно. У меня подозрения, что вылеты программы могли были из-за этого.
Попутно возник еще вопрос, обычно другие объекты внутри класса создаются в конструкторе, но их наверное можно создавать не только в нем, а и в других местах. Главное, что бы потом не было коллизий в диструкторе.

0

Сообщение от NewEmbedder Похоже, что этот порядок не принципиален

код, который подчиняется строгим правилам всегда проще,
чем код, в котором царит бардак.

по этой причине, есть смысл относиться к тезису, как к принципиальному:

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

Сообщение от NewEmbedder но их наверное можно создавать не только в нем, а и в других местах

есть такой анти-паттерн, называется "отложенная инициализация".

суть паттерна в том, что конструктор инициализирует лишь неккий минимум.
настоящая же подготовка объекта к работе выполняется в отдельных методах,
которые называют prepare, statup, init, start,
или ещё каким то подобным образом.

пример:

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

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

и вот что делать в таком случае?
нужно будет в классе хранить какую то дополнительную переменную,
что бы отмечать: была уже подготовка или нет.
и в каждом методе проверять этот флажок.
и если подготовки не было - то каким то образом поднимать тревогу.
а как её поднимать? assert или exception, или как то ещё?

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

а вот если изначально использовать конструктор по назначению,
то всех этих проблем не возникнет в принципе:

и не нужны никакие флажки.
и код в разы проще и надёжнее.

Сообщение от NewEmbedder Главное, что бы потом не было коллизий в диструкторе.

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

1

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

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

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

это не верно. Внутри класса создаются указатели, а их ресурсы навешиваются снаружи (см. опус о неотделимой/отделимой собственности). Но если даже вы решите идти по пути захвата таких ресурсов в порядке зависящем от внешней логики (не задавая жестко в правилах описанных конструкторами), вы должны понимать, что вы требуете от программы понимания внутренней логики вашего класса и её соблюдения. В С++ убивают за гораздо меньшие злодейства. Но свобода - пуще неволи. Ни кто не в силах вам помешать. (Нечаянно опечатлся набирая пословицу и вышло: Но свобода - пpуще неволи. По смыслу тоже подходит). Собственно, hoggy, об этом говорит. Хотя, если продумать ленивые вычисления, то они могут быть полезны. Но это должно быть обоснованно и требует серьёзных усилий. Чревато к тому же.

0

Сообщение от NewEmbedder Вопрос такой, требуется ли в диструкторе уничтожать объекты в порядке обратном по отношению к тому порядку, что был в конструкторе

Не требуется.

Сообщение от NewEmbedder и насколько это важно?

1. "Насколько это важно" в вашем коде известно только вам. Если в вашем коде порядок удаления не играет роли, то используйте удаление в обратном порядке просто как логичное соглашение.

2. Вы вообще не должны в обычных случаях заниматься ручным удалением объектов. За удаление динамических объектов должны отвечать умные указатели. А там уж сам собой получится обратный порядок.

0

Я понял все ваши советы.
Спасибо за квалифицированные разъяснения, вы мне помогли.

0

Сообщение от NewEmbedder Я понял все ваши советы.

Завидую, если честно. Нужно время чтобы понять. NewEmbedder, произвольный порядок инициализации, это наверное, не то, что имеет смысл и возможно, вы имели ввиду, что-то другое. Конструирование объекта как механизм инициализации уравнивает пользовательские типы с примитивными типами С *(что было задекларировано автором языка). Там не предусматривается какой-либо, частичной инициализации. Хотя бы потому, что рождённый объект в случае возможной не завершенности инициализации, будет вынужден постоянно проверять какие-то флаги или значения указателей на предмет равенства nullptr. Однако, если объекты класса чувствительны к окружению на уровне взрывоопасности, а логика зависит от многих (в т.ч. платформенно-зависимых) вещей, проверка которых может надолго связывать какие-то ресурсы, или боже упаси породить исключение, когда объект не может быть создан или ещё что..., то конструктора просто закрывают, а объекты создают в скоупе фабричных, дружественных методов или классов. Там выясняется как будет инициализироваться объект и будет ли он вообще создаваться. То есть, несмотря на расширение возможных вариантов хода инициализации, никто не отдаёт программе, свободу решать эти вопросы. Создаётся некое окружение ответственное за процесс.
Но конструкторы должны быть простыми и надёжными (по возможности), если они публикуются в открытой части класса.

0