The best way is to leave it alone and just use the C API. virtually all programming languages can directly call a C API, so there's no reason to create wrappers unless a particular language's programming model makes more sense a different way.
To clarify what I mean, look at GTK+. It is a C API and is usable in virtually any language. Wrappers exist in object-oriented languages that provide a pure-OOP approach to the GTK+ API because it makes sense for those languages, given the domain of the API.
Does an objectified interface make sense for your application? If not, there is no reason to bother making a C++ wrapper.
As to RPC, why doesn't a simple message-passing interface with shared memory suffice?
manpreet![Tuteehub forum best answer]()
Best Answer
2 years ago
We have an old application which has a FORTRAN API to be called from other applications. After some time they built a ( C ) wrapper for the FORTRAN API.Then I'm now building a c++wrapper , with a little data handling , for the C API.
So I'm thinking what is the best way of building an API that can be called from any programming language.
Now I'm planning to bulde RPC server from my c++ API. Then any client using any programming language can call it.
I found that the XML-RPC is a good one. But it needs HTTP server for connection.
The problem is that the applications that call our API are desktop applications.And I found that XML-RPC can not manipulate complex objects.
Is SOAP a good solution? Can the client side be easily implemented?
So what is the best technical solution for my situation? Which technology should I use?
comment: I do not have a permission for changing the Fortran API and the C API. And I need the c++ API because I'm adding to it new methods , and enhancing the code so the user can call the methods easily.
Best Regards,