Здравствуйте, Shmj, Вы писали:

S>Когда нужно либу на C++ сделать доступной для нормальных (с человеческим лицом) языков программирования — приходится переходить на extern "C". А значит многих фишек C++ уже не будет.
S>К примеру, не будет ссылок — а только указатели.
S>Не будет исключений.

Если библиотека имеет plain C интерфейс, это вовсе не означает, что она должна быть полностью написана на чистом С. Внутри ты можешь спокойно использовать все перечисленное и гораздо больше.

Здравствуйте, Shmj, Вы писали:

S>Когда нужно либу на C++ сделать доступной для нормальных (с человеческим лицом) языков программирования — приходится переходить на extern "C". А значит многих фишек C++ уже не будет.
S>К примеру, не будет ссылок — а только указатели.
S>Не будет исключений.

Если библиотека имеет plain C интерфейс, это вовсе не означает, что она должна быть полностью написана на чистом С. Внутри ты можешь спокойно использовать все перечисленное и гораздо больше.

S>К примеру, некая функция возвращает указатель void*. А внутри там объект класса из C++. Если его получит прога и вызовет calloc.free для этого указателя — вызовется ли деструктор? Нужно ли каждое поле отдельно делать calloc.free ?

Тебе не обязательно возвращать наружу указатели в чистом виде (хотя и такая возможность тоже есть, конечно же). Наружу ты можешь возвращать какие-то безликие дескрипторы, об устройстве и формате которых знаешь только ты. Например, это может быть указатель, закриптованный каким-то нехитрым способом. Или, например, это может быть целочисленный тип 32 или 64 в котором зашифрован индекс типа и индекс объекта. Или еще что-то. Главное то, что все манипуляции с предоставленным тобой ресурсом, включая его освобождение, пользователь должен выполнять через предоставленные тобой же функции, и не пытаться применть к ним какие-нибудь free или delete.