Сообщение Re[19]: Оставаться в С++ или уходить? от 30.09.2019 13:40
Изменено 30.09.2019 13:41 lpd
Re[19]: Оставаться в С++ или уходить?
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Ну в таком случае надо смотреть, а не поможет ли введение внешнего "суперкласса", который будет выполнять удаление и распутывание связей между объектами.
SVZ>Тогда удаление будет выполняться из единой точки, всегда в определенном порядке и проблема циклических зависимостей опять уходит.
Получается что-то вроде GC, только работающего на основе логики иерархии классов приложения, а не указателей. Тоже решение, но почему бы не использовать встроенный GC? Если только из-за скорости. Но и GC можно отключить при необходимости.
И GC и умные указатели(в некоторых специальных случаях) имеют право на жизнь, как и описанный тобой вариант. Но вот в C++ добавили только shared/weak/share_ptr<>. Причем теперь вроде как фанатично агитируют делать все до одного указатели умными, что неудобно и громоздко выглядит в коде.
SVZ>Ну в таком случае надо смотреть, а не поможет ли введение внешнего "суперкласса", который будет выполнять удаление и распутывание связей между объектами.
SVZ>Тогда удаление будет выполняться из единой точки, всегда в определенном порядке и проблема циклических зависимостей опять уходит.
Получается что-то вроде GC, только работающего на основе логики иерархии классов приложения, а не указателей. Тоже решение, но почему бы не использовать встроенный GC? Если только из-за скорости. Но и GC можно отключить при необходимости.
И GC и умные указатели(в некоторых специальных случаях) имеют право на жизнь, как и описанный тобой вариант. Но вот в C++ добавили только shared/weak/share_ptr<>. Причем теперь вроде как фанатично агитируют делать все до одного указатели умными, что неудобно и громоздко выглядит в коде.
Re[19]: Оставаться в С++ или уходить?
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Ну в таком случае надо смотреть, а не поможет ли введение внешнего "суперкласса", который будет выполнять удаление и распутывание связей между объектами.
SVZ>Тогда удаление будет выполняться из единой точки, всегда в определенном порядке и проблема циклических зависимостей опять уходит.
Получается что-то вроде GC, только работающего на основе логики иерархии классов приложения, а не указателей. Тоже решение, но почему бы не использовать встроенный GC? Если только из-за скорости. Но и GC можно отключить при необходимости.
И GC и умные указатели(в некоторых специальных случаях) имеют право на жизнь, как и описанный тобой вариант. Но вот в C++ добавили только shared/weak/share_ptr<>. Причем теперь вроде как фанатично агитируют делать все до одного указатели умными, что неудобней GC, да и громоздко выглядит в коде.
SVZ>Ну в таком случае надо смотреть, а не поможет ли введение внешнего "суперкласса", который будет выполнять удаление и распутывание связей между объектами.
SVZ>Тогда удаление будет выполняться из единой точки, всегда в определенном порядке и проблема циклических зависимостей опять уходит.
Получается что-то вроде GC, только работающего на основе логики иерархии классов приложения, а не указателей. Тоже решение, но почему бы не использовать встроенный GC? Если только из-за скорости. Но и GC можно отключить при необходимости.
И GC и умные указатели(в некоторых специальных случаях) имеют право на жизнь, как и описанный тобой вариант. Но вот в C++ добавили только shared/weak/share_ptr<>. Причем теперь вроде как фанатично агитируют делать все до одного указатели умными, что неудобней GC, да и громоздко выглядит в коде.