Как мы заставили код, портированный с C#, работать с моделью памяти C++

Привет, Хабр. В прошлой статье я рассказывал о том, как мы создали фреймворк для перевода кода C# на (неуправляемый) C++, чтобы выпускать свои библиотеки, изначально разработанные для платформы .Net, и под C++ тоже. В этой статье я расскажу о том, как нам удалось согласовать модели памяти этих двух языков, добившись работы портированного кода в необычном для него окружении.

Я расскажу о том, какие умные указатели мы используем, и почему нам пришлось разработать для них собственные реализации. Я также расскажу о процессе подготовки кода C# к портированию с точки зрения управления временем жизни объектов, о некоторых проблемах, с которыми мы столкнулись, и о специфических способах диагностики, которыми нам приходится пользоваться при работе.
 

Модель работы с памятью в C#

Код C# выполняется в управляемой среде со сборкой мусора. Для наших целей это означает, прежде всего, то, что программист C#, в отличие своего коллеги из числа разработчиков C++, освобождён от необходимости заботиться о возвращении системе выделенной на куче памяти, которая более не используется. За него это делает сборщик мусора (GC) — компонент среды CLR, периодически проверяющий, какие из объектов ещё используются в программе, и очищающий те, на которые больше нет активных ссылок.