IntPtr против указателей C ++

Кажется, я нашел объяснение, которое помогло мне понять, как мне нужно использовать этот IntPtr.

• Закрепление пустого массива
• http://blogs.msdn.com/b/jmstall/archive/2006/10/09/gchandle_5f00_intptr.aspx

Следующий абзац содержит неправильные предложения.

• Я спрашивал, что такое IntPtr, потому что: мне нужно было переместить все мои полезные функции в библиотеку C # (DLL) и в то же время иметь возможность вызывать их из неуправляемых программ, таких как Metatrader. К сожалению, Metatrader вообще не поддерживает указатели, поэтому мне нужно было выяснить, что именно IntPtr возвращает мне, потому что, если это обычный указатель, я не могу использовать его в MT. Также я подумал, что из-за циклов сборки мусора я не могу использовать внутренний указатель, поэтому в любом случае мне нужно закрепить управляемый объект и вернуть точный адрес памяти, с которой он начинается. Я ОШИБАЛСЯ.

Это то, к чему я пришел, уже протестировано и работает, поэтому я считаю, что это правильная реализация.

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

• Я понял, что IntPtr - это указатель на указатель на данные, своего рода void **, но для управляемой кучи, что означает, что есть два указателя, первый указывает на «дескриптор», а «дескриптор» указывает на реальные данные. Второй указатель («дескриптор») может измениться после цикла GC, если фактические данные были перемещены, но адрес этого дескриптора остается прежним, что означает, что первый указатель постоянен в любом случае. Я собирался манипулировать данными только из управляемого кода, поэтому достаточно было сохранить только первый указатель, а затем, используя этот указатель, я всегда могу получить «дескриптор», независимо от того, было ли его значение изменено GC или нет. Дан хэндл - может сам получить данные.

• для меня шаблоны int_ptr <> и interrior_prt <> кажутся черным ящиком, поэтому, если бы я их использовал, вероятно, было бы сложнее понять, как именно работают эти дескрипторы, возможно, я скоро передумаю, но пока я реализовал это с помощью GCHandle

Пример:

Скажем, у меня есть класс в C # DLL, который я хотел бы использовать в качестве общей памяти через файлы с отображением памяти, я назвал его подключением:

http://www.codeproject.com/Articles/138290/Programming-Memory-Mapped-Files-with-the-NET-Frame

Затем в C ++ / CLI у меня есть:

#define ECV extern "C" __declspec(dllexport) void __cdecl

ECV MemoryOpen(char * name, int size, int &pointer)
{
    try
    {
        Connection ^ memory = gcnew Connection(); // instantiate managed class
        GCHandle gc = GCHandle::Alloc(memory); // get handle
        pointer = (int) GCHandle::ToIntPtr(gc); // get pointer to handle and pass it to unmanaged code by reference
        memory->Open(gcnew String(name), size); // do something from managed code
    }
    catch (Exception ^ e)
    {
        MessageBox::Show(e->Message + " " + e->StackTrace);
    }
}

ECV MemoryClose(int pointer)
{
    try
    {
        GCHandle gc = GCHandle::FromIntPtr(IntPtr(pointer)); // get pointer to handle
        Connection ^ memory = (Connection ^) gc.Target; // get data using handle
        memory->Close();
        gc.Free(); // free handle
    }
    catch (Exception ^ e)
    {
        MessageBox::Show(e->Message + " " + e->StackTrace);
    }
}