Сообщение Re[8]: Приоритет вызова перегруженных методов от 07.06.2016 15:06
Изменено 07.06.2016 15:09 Serginio1
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>> То есть использование любых сборок из Натива.
S>>>В общем случае нереально.
S>> Реально. Кратко. Объекты хранятся в массивах. Передаются индексы в массивах. На стороне 1С есть метод
S>Оно будет работать или для вызовов managed->native, или для случаев, когда объекты живут не дольше, чем время вызова native->managed. Иначе получаем или утечку объектов на managed-стороне, или порчу памяти из-за пожраного GC объекта, или адскую магию с рефкаунтингом (по, сути, переизобретение IUnknown).
Не читаешь ты. Прежде чем отправить в натив объект сохраняется в статическом массиве массиве. Жить он будет пока его из массива не удалят.
На стороне 1С есть подсчет ссылок и
S>Довольно существенное ограничение.
S>Если устраивает — всё сводится к получить на managed-стороне массив объектов-параметров + тип + имя метода. Дальше всё как в первом ответе написал, второй вариант.
S>> DLR не подходит. Я не знаю заранее, что вызовется. В DLR уже известна сигнатура.
S>Вообще-то неизвестна, в рантайме определяется. Достаточно только набора значений.
DLR то как раз статический. Но он мне все равно нужен для использования DynamicObject
Кстати попробовал на стороне Манагед
И вызов
Marshal такой же как и во взрослом. А значит могу ползать по памяти как хочу.
S>Здравствуйте, Serginio1, Вы писали:
S>>>> То есть использование любых сборок из Натива.
S>>>В общем случае нереально.
S>> Реально. Кратко. Объекты хранятся в массивах. Передаются индексы в массивах. На стороне 1С есть метод
S>Оно будет работать или для вызовов managed->native, или для случаев, когда объекты живут не дольше, чем время вызова native->managed. Иначе получаем или утечку объектов на managed-стороне, или порчу памяти из-за пожраного GC объекта, или адскую магию с рефкаунтингом (по, сути, переизобретение IUnknown).
Не читаешь ты. Прежде чем отправить в натив объект сохраняется в статическом массиве массиве. Жить он будет пока его из массива не удалят.
На стороне 1С есть подсчет ссылок и
S>Довольно существенное ограничение.
S>Если устраивает — всё сводится к получить на managed-стороне массив объектов-параметров + тип + имя метода. Дальше всё как в первом ответе написал, второй вариант.
S>> DLR не подходит. Я не знаю заранее, что вызовется. В DLR уже известна сигнатура.
S>Вообще-то неизвестна, в рантайме определяется. Достаточно только набора значений.
DLR то как раз статический. Но он мне все равно нужен для использования DynamicObject
Кстати попробовал на стороне Манагед
public static int TestFunctionIntPtr(IntPtr i)
{
int res = Marshal.ReadInt32(i);
return res;
}
И вызов
typedef int (STDMETHODCALLTYPE *ManagedMethodIntPtr)(int*);
ManagedMethodIntPtr pTestFunctionIntPtr;
//TestFunctionIntPtr
hr = CreateDelegate2(pCLRRuntimeHost, domainId, L"CoreClrDLL", L"CoreClrDLL.Program", L"TestFunctionIntPtr", (INT_PTR*)&pTestFunctionIntPtr);
if (FAILED(hr))
{
printf_s("Failed to create a delegate to the managed entry point: (%d).\n", hr);
}
else
{
cout << "Press Key";
cin.get();
int i = 555;
printf_s("result method pTestFunctionIntPtr(555) : (%d).\n", pTestFunctionIntPtr(&i));
}
Marshal такой же как и во взрослом. А значит могу ползать по памяти как хочу.
Re[8]: Приоритет вызова перегруженных методов
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>> То есть использование любых сборок из Натива.
S>>>В общем случае нереально.
S>> Реально. Кратко. Объекты хранятся в массивах. Передаются индексы в массивах. На стороне 1С есть метод
S>Оно будет работать или для вызовов managed->native, или для случаев, когда объекты живут не дольше, чем время вызова native->managed. Иначе получаем или утечку объектов на managed-стороне, или порчу памяти из-за пожраного GC объекта, или адскую магию с рефкаунтингом (по, сути, переизобретение IUnknown).
Не читаешь ты. Прежде чем отправить в натив объект сохраняется в статическом массиве массиве. Жить он будет пока его из массива не удалят.
На стороне 1С есть подсчет ссылок и Done() при разрушении объекта, которое я могу ипользовать для удаления из массива.
Кроме того можно освобождать все ссылки при разрушении домена
S>Довольно существенное ограничение.
S>Если устраивает — всё сводится к получить на managed-стороне массив объектов-параметров + тип + имя метода. Дальше всё как в первом ответе написал, второй вариант.
S>> DLR не подходит. Я не знаю заранее, что вызовется. В DLR уже известна сигнатура.
S>Вообще-то неизвестна, в рантайме определяется. Достаточно только набора значений.
DLR то как раз статический. Но он мне все равно нужен для использования DynamicObject
Кстати попробовал на стороне Манагед
И вызов
Marshal такой же как и во взрослом. А значит могу ползать по памяти как хочу.
S>Здравствуйте, Serginio1, Вы писали:
S>>>> То есть использование любых сборок из Натива.
S>>>В общем случае нереально.
S>> Реально. Кратко. Объекты хранятся в массивах. Передаются индексы в массивах. На стороне 1С есть метод
S>Оно будет работать или для вызовов managed->native, или для случаев, когда объекты живут не дольше, чем время вызова native->managed. Иначе получаем или утечку объектов на managed-стороне, или порчу памяти из-за пожраного GC объекта, или адскую магию с рефкаунтингом (по, сути, переизобретение IUnknown).
Не читаешь ты. Прежде чем отправить в натив объект сохраняется в статическом массиве массиве. Жить он будет пока его из массива не удалят.
На стороне 1С есть подсчет ссылок и Done() при разрушении объекта, которое я могу ипользовать для удаления из массива.
Кроме того можно освобождать все ссылки при разрушении домена
pCLRRuntimeHost->UnloadAppDomain(domainId, true);
// Stop the runtime host
pCLRRuntimeHost->Stop();
S>Довольно существенное ограничение.
S>Если устраивает — всё сводится к получить на managed-стороне массив объектов-параметров + тип + имя метода. Дальше всё как в первом ответе написал, второй вариант.
S>> DLR не подходит. Я не знаю заранее, что вызовется. В DLR уже известна сигнатура.
S>Вообще-то неизвестна, в рантайме определяется. Достаточно только набора значений.
DLR то как раз статический. Но он мне все равно нужен для использования DynamicObject
Кстати попробовал на стороне Манагед
public static int TestFunctionIntPtr(IntPtr i)
{
int res = Marshal.ReadInt32(i);
return res;
}
И вызов
typedef int (STDMETHODCALLTYPE *ManagedMethodIntPtr)(int*);
ManagedMethodIntPtr pTestFunctionIntPtr;
//TestFunctionIntPtr
hr = CreateDelegate2(pCLRRuntimeHost, domainId, L"CoreClrDLL", L"CoreClrDLL.Program", L"TestFunctionIntPtr", (INT_PTR*)&pTestFunctionIntPtr);
if (FAILED(hr))
{
printf_s("Failed to create a delegate to the managed entry point: (%d).\n", hr);
}
else
{
cout << "Press Key";
cin.get();
int i = 555;
printf_s("result method pTestFunctionIntPtr(555) : (%d).\n", pTestFunctionIntPtr(&i));
}
Marshal такой же как и во взрослом. А значит могу ползать по памяти как хочу.