Ні, подвійного видалення не буде

{
    MyLinkedList myList;
    myList.addAtHead(10);
    myList.addAtHead(20);
    myList.addAtIndex(1, 15);
} // <-- call `myList` destructor `MyLinkedList::~MyLinkedList()`
  //    +--> call `head` destructor `unique_ptr<Node>::~unique_ptr<Node>()` [початок рекурсивного ланцюжка]
  //       +--> call `ptr` destructor `Node::~Node()`
  //          +--> call `next` destructor `unique_ptr<Node>::~unique_ptr<Node>()`
  //             +--> call `ptr` destructor `Node::~Node()`
  //                +--> call `next` destructor `unique_ptr<Node>::~unique_ptr<Node>()`
  //                 ...

При виході зі скоупу почнеться виклик дефолтного деструктора MyLinkedList::~MyLinkedList(), оскільки він дефолтний він просто тригерне деструктори мемберів, у нашому випадку маємо лише одного мембера -- unique_ptr<Node> head. Після чого ми потрапимо в деструктор Node::~Node(), який теж дефолтний та просто почне виклик деструктор свого мембера, тобто std::unique_ptr<Node> next. Ну і так далі. Видалення в цьому випадку можливе лише з першого вузла (голови), адже це єдиний член списку. Рекурсія не може початись з останнього вузла. Тому не важливо, куди ми впихнемо останнє значення в список (на початок, в середину чи кінець).

Видалив.

Не вдивлявся сильно в імплементацію ТС, але std::move викликатиме reset та release за вас, проте це все ще не означає, що не потрібно бути уважним та дивитись що куди мувається. Але, проблема коли список вийде за скоуп та почнеться рекурсивний виклик деструкторів до глибини n (де n довжина списку) -- залишається. Не те щоб цю проблему не можна було б вирішити, але тоді якось весь сенс у використані std::unique_ptr втрачається, на мою думку. Загалом розумні вказівники не зовсім були створені саме для таких випадків, їхній скоуп використання дещо інший. З іншої сторони, це теж можливість трохи набити синців та самостійно розібратися в проблемі.

Щодо індексів повністю згоден, але це ж задачка з LeetCode. Там швидше тебе намагаються "навчити" вирішувати конкретні завдання, а не дати глибоке розуміння предметної області.

Я б радив спершу почитати, що таке той Linked List, як Data Structure. А, вже потім би брався його імплементовувати в певній мові.

1. Це не шаблон типу.
2. А, який тип там тоді мав би бути на вашу думку?

Хз, поставте це питання автору, код якого ви позичили.

leofun01, ймовірно тре пояснити детальніше. Мені написала HRка щодо вакансії, скинувши типовий коротенький опис + запросила на кол (~10хв). Оскільки вона спілкувалася українською, я початково думав, що це пишуть з якоїсь української галери, яка займається аутсорсом чи аутстафом. На колі вона запитала мене про очікувану зарплату, де я й назвав суму, яку типово називаю для українських галер. Я трохи протупив, бо вона казала, що компанія ірландська і контракт буде з ними напряму, а не через якусь українську компанію (як це типово буває). Я цю інформацію прийняв, але толком не обробив (цей тиждень якийсь дикий був). Потім була технічна співбесіда в інший день, яку я пройшов і того ж дня, ввечері, мені вона відписала, що їм все сподобалось, тому готові пропонувати офер. То ж, чекаю офер, має бути на початку наступного тижня. І зараз, на цьому етапі, я розумію, що трохи продешевив, от.

Це я помітив, Ірландці круті.

Тут не зовсім так, через специфіку проєкту, як я розумію, будь-що не підійде. Потрібно буде щось точно з більш-менш хорошою відеокартою, хоча я ще не встиг обговорити конфігурацію. Сфера все ж геймдев/графіка/3D.

Гм, +500 було б не так і погано, але от не знаю, якби це так до цього питання підійти й натякнути)

Я для шорткатів мови юзав kawa, єдиний мінус під ARM проц треба ручками перекомпілювати, але на диво у мене все працювало гуд.

Є таке, я помічав, що це ще може залежати від HDMI кабеля. Купівля просто якіснішого мені допомогла. Але ще можна спробувати скористатись BetterDisplay тулзою.

Для мене в свій час це були основні плюси, які в цілому позитивно змінили моє ставлення до ноутбуків.

Покажіть мені ноутбук від hp на ARM-процесорі з такими ж конфігураціями та продуктивністю, які пропонує mac. Тоді можемо поговорити за ціни.

Як розуміти оце ваше: "на Windows 11 (MSVC) — такий підхід не спрацював"? Програма не компілюється чи може вона форматує диск, замість збереження даних?

Знову ж таки, дивлячись, які дані ви зберігаєте та в якій кількості? Як часто користувач може робити ці зміни тощо?
Якщо це не багато інформації яку необхідно зберегти, а користувач ймовірніше за все робитиме ці зміни не часто, то чому б не зберігати її одразу після того, як користувач змінив налаштування?

Сенс у відкладеному зберіганні є, якщо ви знаєте, що ймовірніше за все, користувач може часто щось оновлювати. Тому, щоб багато раз не зберігати маленькі шматочки інформації, ви чекаєте поки не накопичиться більше інформації, щоб потім залпом її зберегти за один виклик.

Мені чомусь здається, що ви знову чогось не договорюєте.. Це точно весь вивід, який вам видав зневаджувач? Ех.. Ну, гаразд, яке питання..
З погляду D3D11, це попередження з'являється якщо ви створили InputLayout компонентів з таким типом:

D3D11_INPUT_ELEMENT_DESC inputLayout[] =
{
    { "TEXCOORD", 0, DXGI_FORMAT_R16G16_UINT, 0, 0, D3D11_INPUT_PER_VERTEX_DATA, 0 },
    /* інші компоненти "COLOR", "POSITION" тощо. */
};
d3d11Device->CreateInputLayout(inputLayout, numElements, ...);

Зверніть увагу на вказаний тип компонента -- DXGI_FORMAT_R16G16_UINT.
Але у вершинному шейдері тип цього компонента було вказано іншим, як от

struct VertexShaderInput
{
    int2 texcoord : TEXCOORD;
    /* інші компоненти "COLOR", "POSITION" тощо. */
};

Тут тип вже вказано int2 (тобто int32), хоча мало б бути щось типу ushort2 (тобто uint16). Але як я пам'ятаю HLSL підтримує 16-бітні типи лише з переданим ключиком -enable-16bit-types.
Щоб це виправити потрібно виправити шейдер або те, як ви створюєте InputLayout. Ну, або знати більше контексту, хто і звідки це кидає. Не виключено, що це може бути баг і у самому Qt.