А>есть функция DLLFunction, которая принимает параметр void *, а на конечном языке описать класс

А>class CClassForDLLFunction;

А>в котором будет одна из функций ExecDLLFunction(int a,int b);

А>И эта функция будет передавать функции DLLFunction структуру, в которой будут два параметра "a" и "b".

А>Примерно так ?
хм... ООП так ООП! Оперируем объектами.Опишем некоторый класс (пример из жизни ):

public class Matrix
{
    private double[,] fData;
    public Vector SolveByGausse(Vector atc) // solves system defined by the matrix using Absolute Term Column
    {
        return (Vector)DLLFuncSolveByGausse((void *)atc); // вроде так в c++  :shuffle: 
    }
    public int Summarize(int a, int b) { return DLLFuncSummarize(int a, int b); }
}

В случае простых функций, вроде "посчитать a+b" в библиотеке так и пишем int Summarize(int a, int b) { return a+b; }
В случае сложных (которые получают объект на входе) надо проверить на COM-совместимость используемых вами в библиотеке методов работы с такими вот классами+проверить на COM-совместимость целевых ООЯзыков. То есть в библиотеке нужно реализовать подобную (если не идентичную ) Классовую модель, но с готовой реализацией. То есть в методе DLLFuncSolveByGausse мы предполагаем, что нам передали объект класса Vector и нам нужно его обработать (в частности вызвать его функцию, например). Тогда нужно в библиотеке иметь COM-совместимую реализацию класса Vector и работать только с COM-совместимыми возможностями языка.
Вся эта "COM-совместимость" необходима, чтобы достичь взаимопонимания между разными языками. Все не COM-совместимые фичи языка скорее всего не будут поддерживаться в другом языке. Это не важно при реализации библиотеки (поскольку объекту класса Matrix абсолютно все равно, что делается внутри функции DLLFuncSummarize) до тех пор, пока мы не работаем с объектами, передаваемыми через параметр. Фактически такой объект создан в другой среде и вообще говоря структура его, хранимая в памяти, в целом отличается от той, которую бы имел объект класса, описанного на языке, на котором писалась библиотека. Но как правило современные ООЯ поддерживают некоторую совместимость, описываемую COM-технологией (современный ООЯ как правило способен работать с COM-компонентами) и называемую COM-совместимостью (это как правило размещение в памяти виртуальной таблицы по адресу объекта и кое-что еще). Этим и можно воспользоваться. В рассмотренном примере опасных мест два:
1) передаем параметром Vector. Значит в библиотеке работаем только с COM-совместимой частью объекта.
2) возвращаем Vector. Это еще хуже: это обязывает и в конечной реализации работать только с COM-совместимой частью возвращенного объекта.

Так, при создании объекта и там, и там можно пользоваться нативными способами, но доступ к необходимой для работы в другой среде части объекта придется описывать только совместимыми способами. Вот.

N>>С темой вроде "париться писать под каждый язык не охота" можно совладать использованием многоцелевых средств моделирования
А>А это как, поясните пожалуйста.

Структуры будущих классов разработать один раз в каком-нибудь средстве проектирования, а оттуда уже (если средство хорошее) проводить генерацию кода для целевых сред.