Как gcc в MinGW подружить с VS CODE (visual studio code), чтобы можно было прямо в консоли программы видеть исполнение?

Забавный нюанс, если вы будете использовать clang, и хотите что бы он собирал код под платформу которая не является его дефолтной, например x86_64-pc-windows-msvc (Visual Studio). То вы можете сделать копию бинарника clang.exe, назвать его i686-w64-mingw32-clang.exe то по дефолту он начнёт собирать код под mingw-w64 32bit. Это избавляет от необходимости указывать ему флаг --target=i686-w64-mingw32 и по умолчанию он начнёт искать в PATH binutils с таким же префиксом, например i686-w64-mingw32-gcc i686-w64-mingw32-ld i686-w64-mingw32-ar и т.д.

Как gcc в MinGW подружить с VS CODE (visual studio code), чтобы можно было прямо в консоли программы видеть исполнение?

Самый простой вариант сделать симлинк на бинарник VS Code, в командной строке от администратора выполняем mklink C:\MinGW\bin\vscode.exe "C:\Program Files (x86)\Microsoft VS Code\Code.exe"
Затем запускаем bash входящий в состав MinGW, например C:\MinGW\msys\1.0\msys.bat
А уже из bash запускаем VS Code вызывая просто vscode (симлинк который создавался ранее), таким образом запущенный VS Code наследует все переменные окружения, в том числе и PATH которые определяет MinGW. Это избавит от необходимости прописывать что либо в системный или пользовательский Path операционной системы, так как MinGW/Cygwin/Msys2 определяют необходимые им переменные окружения при запуске встроенной в них консоли. Подобный подход избавляет от многих проблем связанных с зависимостями gcc или clang от окружения в котором они выполняются.

Как gcc в MinGW подружить с VS CODE (visual studio code), чтобы можно было прямо в консоли программы видеть исполнение?

Вроде как вот тут https://code.visualstudio.com/docs/languages/cpp подробно расписано, только один нюанс, лучше запускать VS Code непосредственно из MinGW/Cygwin/Msys2 если ваш GCC является их составной частью.

Как правильно отчистить память после работы приложения?

Ну да, при использовании ARC не обязательно писать свою реализацию release, однако если используются примитивы из C память для которых выделялась путем malloc calloc realloc то нужно писать свою реализацию метода dealloc, на пример если используются элементы CoreFoundation.

Как правильно отчистить память после работы приложения?

А вот тут по подробнее пожалуйста. Прям запретили? Не скомпилируется теперь, если я пошлю объекту release? Правда хочется узнать, потому что полгода назад все вроде посылалось.