Надежное обеспечение безопасности памяти в C++ 14

Я преобразовываю старый код C++ для использования shared_ptr, unique_ptr и weak_ptr и продолжаю сталкиваться с проблемами проектирования.

У меня есть методы «генератора», которые возвращают новые объекты, и методы доступа, которые возвращают указатели на существующие объекты. На первый взгляд решение кажется простым; вернуть shared_ptr для новых объектов и weak_ptr для средств доступа.

shared_ptr полностью избегает висячих указателей, поскольку, если объект когда-либо будет удален, все его общие и слабые указатели узнают об этом. Но я продолжаю сталкиваться со случаями, когда я не уверен, есть ли циклические ссылки среди моих общих указателей. Классов много, и некоторые из них указывают друг на друга; возможно ли, что в какой-то момент сформировался цикл? Код настолько сложен, что трудно сказать - новые классы создаются по инструкциям в файле скрипта. Так что я не знаю, действительно ли shared_ptr предотвращает утечку памяти и вручную удаляет все объекты, что, кажется, противоречит сути.

Вместо этого я решил использовать unique_ptr, так как мне фактически не нужно где-либо совместное владение. (В старом коде C++, конечно, не было общего владения, это были только необработанные указатели.) Но я не могу сделать weak_ptrs из unique_ptr, поэтому мне приходится использовать необработанные указатели в качестве заменителей для слабых указателей. Это решает проблему утечки памяти, но я могу остаться с оборванными указателями, когда unique_ptr будет уничтожен.

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

Люди говорили мне, что мне нужно держать всю структуру программы в голове, чтобы я мог убедиться, что нет циклов с общими указателями, но это кажется подверженным ошибкам. Моя голова, в конце концов, только такая большая. Есть ли способ обеспечить безопасность памяти, учитывая только локальный код?

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