Sazoks

https://docs.python.org/2/faq/design.html#how-are-...

How are lists implemented in CPython?¶
CPython’s lists are really variable-length arrays, not Lisp-style linked lists. The implementation uses a contiguous array of references to other objects, and keeps a pointer to this array and the array’s length in a list head structure.

This makes indexing a list a[i] an operation whose cost is independent of the size of the list or the value of the index.

When items are appended or inserted, the array of references is resized. Some cleverness is applied to improve the performance of appending items repeatedly; when the array must be grown, some extra space is allocated so the next few times don’t require an actual resize.

Короче динамический массив. Непрерывный массив указателей на объекты

Стоит. Даже более того. Со временем можно прийти к тому что на книжной полке с десяток книг с закладками, которые вначале бегло просматриваются, а потом читаются и перечитываются по мере необходимости. Очень интересно наблюдать профессоров старой школы с большими библиотеками. У них часто именно такой режим чтения: читать, делать пометки, возвращаться снова.

А каша зависит от индивидуальной организации мышления. Кто-то может, кто-то нет. Из хорошего - это тренируется.

Если не осталось ссылок на объект в памяти(счетчик ссылок на объект = 0 (на самом деле не совсем 0, но это уже связано со внутренними механизмами интерпретатора, это нас волновать не должно)) - объект удаляется сборщиком мусора. За удаление объектов вам переживать не стоит.
Т.е. в вашем примере, ссылки на объект еще остались (a = x[4]), поэтому автоматически не происходит удаление объекта.

Если используете PyCharm то там в настройках интерпретатора вы должны поставить python, в котором она установлена. По крайней мере на Linux это так, если вы используете не PyCharm то можете переустановить python, у меня на windows такое бывало.

Начинать разбираться отсюда:
https://docs.microsoft.com/en-us/cpp/windows/deplo...

Вызов конструктора Parent считается частью вызова конструктора Child. И он происходит раньше, чем конструирование всех полей, добавленных в Child — и уж тем более до тела Child::Child.

Открою секрет )
Пишите тесты. Тесты невозможно написать на плохую архитектуру. Делая новый класс, думайте как будете его тестировать. У вас сразу появится стремление выполнять половину принципов SOLID. (даже если вы их не знаете). Стремление сделать классы лаконичными. С хорошим интерфейсом. Стремление разбивать приложение на компоненты.
Про это много есть статей. тестируемость и архитектура.
Затем можно почитать какие-нибудь книжки. Для начала Роберта Мартина PPP - дословно не помню) но три пи легко можно найти и перевод. (он для C# вроде, но книга классная)
Попробуйте TDD. В работе возможно она не будет нужна, но ухватить идею как создается хороший интерфейс можно.
Затем постоянно себе напоминать, что код пишется для программиста (не для компилятора). Т.е. код это объяснение другому (более тупому))) программисту как это работает. Из этого: хорошие названия - 80% успеха. Остальное архитектура и проч.
Читать код. Свой, чужой, бест практики.
То что свой код бесит - это нормально. Плохо если старый код нравится - значит рост прекратился. Это тревожный звоночек.
Итого.
1)Начинайте свой рост с умения писать тестируемый код.
2) когда почувствуете жжение нехватки опыта в конкретных механизмах (паттернах, принципах) начинайте читать книги.
3) пишите код для тупых программистов (это скромность)
4) быть вне зоны комфорта это нормально.
5+) Почитывайте книги Чистый код Мартина и Совершенный Код Макконнелла (те главы которые вам "заходят")
Удачи в умении сделать сложное простым.)

Вроде все работает, все более менее оптимизировано, но мне все равно кажется, что мой код ужасен. ПРОСТО УЖАСЕН.

В принципе, не существует идеального кода, просто банально потому, что насчет этого существуют как минимум два разных мнения.
Что бы проверить, насколько код ужасен - внедрите новую фичу в ваш проект - если это сделать сложно, без изменения нынешней структуры, тогда вам нужен Рефакторинг, что как бы и подразумевает, что вы будете улучшать именно архитектуру. Рефакторинг можно применять до бесконечности, наделяя архитектуру новыми плюсами и новыми минусами.

Практический опыт важнее теории. По крайней мере изучение архитектуры уже предполагает наличие опыта

Начните с хрестоматийного трёхтомника Роберта Мартина "Чистый код", "Чистая архитектура" и "Идеальный программист".

Первое что стоит сделать - переустановить драйвер. Полностью, мануал тут, вы не первый столкнулись https://pc-consultant.ru/rabota-na-komp-yutere/ati...

В целом они нужны что бы ненужно было думать об освобождении ресурсов вручную.
unique_ptr - просто хранит динамический объект, когда будет уничтожен unique_ptr он автоматически освободит память с этим объектом.
shared_ptr нужен когда есть несколько объектов работающих с одним экземпляром. shared_ptr указывающие на один и тот же объект сами считают свое количество и память будет очищена при уничтожении последнего.
weak_ptr нужен если существует два объекта хранящих умные указатели друг на друга. Если их обоих сделать shared_ptr то программа не очистит память при попытке удалить один из них, так как уйдет в бесконечную рекурсию в попытке удалить их. Для решения есть weak_ptr он просто следит за своим объектом и не мешает его удалению, но может принять право владения если не будет других shared_ptr.

Вам нужен ментор/тимлид/код-ревьюер. Это самый быстрый и рабочий способ.

Подскажите, как лучше поступить в моем случае?

Узнать чем статические методы класса отличаются от обычных методов.
Узнать, что кроме указателей на функции бывают указатели на функции-члены.
Понять, чем из этого лучше воспользоваться в твоём случае.