shared pointers
давно подозревал, что постоянная возня руками с .data() умных указателей unique_ptr/QScopedPtr, особенно с передачей за пределы динамически созданного хозяина - намёк на плохой дизайн.
Время жизни жёстко контролируется в одном месте, а использование происходит в другом, и они никак не сцеплены.
Я преположил, что это хороший повод использовать Shared Pointers, но по сути дела они даже не размазывают контроль, а полностью лишают нас контроля - ведь любые ошибки обращения после уничтожения хозяина говорят о том, что МЫ не понимаем, как работает наша логика, а наш SharedPtr - это просто мини-сборщик мусора, который предотвратит падение программы но никак не починит наше неполное знание о её поведении.
Есть ещё вариант со схемой shared_ptr + weak_ptr - по сути дела это просто более технологический вариант проверки на NULL перед использованием указателя, и он тоже не никак не восполняет наше знание о поведении программы.
Есть подозрение, что сама схема «работник как ресурс» фундаментально эпистемологически порочна.
С другой стороны, чисто формально под эту категорию попадает... вообще всё
Время жизни жёстко контролируется в одном месте, а использование происходит в другом, и они никак не сцеплены.
Я преположил, что это хороший повод использовать Shared Pointers, но по сути дела они даже не размазывают контроль, а полностью лишают нас контроля - ведь любые ошибки обращения после уничтожения хозяина говорят о том, что МЫ не понимаем, как работает наша логика, а наш SharedPtr - это просто мини-сборщик мусора, который предотвратит падение программы но никак не починит наше неполное знание о её поведении.
Есть ещё вариант со схемой shared_ptr + weak_ptr - по сути дела это просто более технологический вариант проверки на NULL перед использованием указателя, и он тоже не никак не восполняет наше знание о поведении программы.
Есть подозрение, что сама схема «работник как ресурс» фундаментально эпистемологически порочна.
С другой стороны, чисто формально под эту категорию попадает... вообще всё