давно подозревал, что постоянная возня руками с .data() умных указателей unique_ptr/QScopedPtr, особенно с передачей за пределы динамически созданного хозяина - намёк на плохой дизайн
( Read more... )
Так использование умных указателей вообще же не подразумевает работу с .data() .get(). Тип, положено обращаться только к методам типа, прося его что-то со своими данными сделать, либо передавать/делить владение объектом.
А иначе, да, получается, просто заметание мусора под ковер.
Эфемерные данные в стек не поместятся в общем случае. Вы правы в том, что это не проблема управления памятью, при "забывании" освободить ссылку на объект никакой мусорщик не поможет, разве что добавить время жизни к объекту, по истечении которого он будет уничтожен вне зависимости от. Но это выглядит как костыль.
Судя по вашему описанию, проблема лежит не в подсистеме воркеров, а на стороне их использования. Т.е. надо подумать над интерфейсом воркеров, который будет контроллировать пользователя. Либо, зная, что пользователи в любом случае будут как попало обращаться с данными, полностью изолировать их процессы и наложить на них разумные ограничения, по времени, памяти, денег и т.д.
Comments 4
Тип, положено обращаться только к методам типа, прося его что-то со своими данными сделать, либо передавать/делить владение объектом.
А иначе, да, получается, просто заметание мусора под ковер.
Reply
Reply
Судя по вашему описанию, проблема лежит не в подсистеме воркеров, а на стороне их использования. Т.е. надо подумать над интерфейсом воркеров, который будет контроллировать пользователя. Либо, зная, что пользователи в любом случае будут как попало обращаться с данными, полностью изолировать их процессы и наложить на них разумные ограничения, по времени, памяти, денег и т.д.
Reply
Reply
Leave a comment