Сообщение Re[17]: Оставаться в С++ или уходить? от 30.09.2019 13:02
Изменено 30.09.2019 13:03 lpd
Re[17]: Оставаться в С++ или уходить?
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, lpd, Вы писали:
SVZ>[A->B;B->A] можно оставить.
SVZ>Определяем иерархию — есть родительский объект, есть дочерние. Родительский объект отвечает за время жизни дочерних.
SVZ>"Умер папа, умерли и дети".
SVZ>Это позволяет сделать weak ссылки между объектами в иерархии.
Например у меня в сервере деление на родительские и дочерние объекты было не всегда(для сессий соединения, пользователей). Особенно если у многих из родительских есть ссылки на несколько дочерних, общих с другими родительскими, и время жизни разное. Так что такая схема не во всех случаях хорошо подходит. Точнее, счетчик ссылок(c shared/weak указателями) в таком случае это один из вариантов, и неплохой, но GC бы справился лучше и проще.
SVZ>Здравствуйте, lpd, Вы писали:
SVZ>[A->B;B->A] можно оставить.
SVZ>Определяем иерархию — есть родительский объект, есть дочерние. Родительский объект отвечает за время жизни дочерних.
SVZ>"Умер папа, умерли и дети".
SVZ>Это позволяет сделать weak ссылки между объектами в иерархии.
Например у меня в сервере деление на родительские и дочерние объекты было не всегда(для сессий соединения, пользователей). Особенно если у многих из родительских есть ссылки на несколько дочерних, общих с другими родительскими, и время жизни разное. Так что такая схема не во всех случаях хорошо подходит. Точнее, счетчик ссылок(c shared/weak указателями) в таком случае это один из вариантов, и неплохой, но GC бы справился лучше и проще.
Re[17]: Оставаться в С++ или уходить?
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, lpd, Вы писали:
SVZ>[A->B;B->A] можно оставить.
SVZ>Определяем иерархию — есть родительский объект, есть дочерние. Родительский объект отвечает за время жизни дочерних.
SVZ>"Умер папа, умерли и дети".
SVZ>Это позволяет сделать weak ссылки между объектами в иерархии.
Например у меня в сервере деление на родительские и дочерние объекты было не всегда(для сессий соединения, пользователей). Особенно если у многих из родительских есть ссылки на несколько дочерних, общих с другими родительскими, и время жизни разное. Так что такая схема не во всех случаях хорошо подходит. Точнее, счетчик ссылок(c shared/weak указателями) в таком случае это один из вариантов, и не самый плохой, но GC бы справился лучше и проще.
SVZ>Здравствуйте, lpd, Вы писали:
SVZ>[A->B;B->A] можно оставить.
SVZ>Определяем иерархию — есть родительский объект, есть дочерние. Родительский объект отвечает за время жизни дочерних.
SVZ>"Умер папа, умерли и дети".
SVZ>Это позволяет сделать weak ссылки между объектами в иерархии.
Например у меня в сервере деление на родительские и дочерние объекты было не всегда(для сессий соединения, пользователей). Особенно если у многих из родительских есть ссылки на несколько дочерних, общих с другими родительскими, и время жизни разное. Так что такая схема не во всех случаях хорошо подходит. Точнее, счетчик ссылок(c shared/weak указателями) в таком случае это один из вариантов, и не самый плохой, но GC бы справился лучше и проще.