axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Damitha Kumarage" <>
Subject Re: C bindings for 1.5
Date Wed, 01 Dec 2004 08:46:45 GMT
On Tue, 30 Nov 2004 15:15:10 +0000, Mark Whitlock wrote
> Hi,
> I am investigating what the C bindings will look like in 1.5. There are
> several parts to implementing the C bindings: the dynamic client API 
> for C
> (using the Call interface without generated stubs), the generated C 
> stubs, C services and C handlers. I will implement the dynamic 
> client API first, then the generated C stubs. As previously agreed 
> on the mailing list, I'll separate out the C support into separate 
> header files, separate source files and link it into a separate 
> dll/shared library. So this is what I propose....
> I'll create the C header files in include/axis, include/axis/client and
> include/axis/server. There will be a .h header file for each .hpp header
> file. So there will be a Call.hpp for C++ and a Call.h for C. All 
> the C++ definitions are in the axiscpp namespace to avoid 
> nameclashes with user definitions, but in C this is not possible, so 
> all definitions need to be prefixed. #defines will be prefixed with 
> AXIS. Functions will be prefixed with axis. Functions that map to 
> instance methods will take as their first parameter an AXISHANDLE 
> which will allow the C binding to keep track of the C++ instance. So...
> int axiscpp::Call::setEndpointURI(const char *pchEndpointURI);     
> // old C++ version
> #define AXISHANDLE void*
> int axisSetEndpointURI(AXISHANDLE call, const char *pchEndpointURI);
> // new C version

Isn't it better to use axisc instead of axis
ie. axiscSetEndpointURI... AXISCHANDLE?

> The implementation of these new C bindings will be a very thin 
> layer. The source files for the C bindings will be in ws-
> axis/c/src/cbindings and will be linked into AxisClientC.dll on 
> Windows, with other suitable names on other platforms. So C 
> applications will link with AxisClientC, C++ applications will link 
> with AxisClient and AxisClientC will be linked with AxisClient.


> The C header files will not include the C++ headers and the C++ headers
> will not include the C headers. There will be C functions that map to
> constructors and destructors for C++ objects. These will be "create" 
> and "destroy" functions such as...
> Call::Call();   // C++ version
> Call::~Call(); // C++ version
> AXISHANDLE axisCreateCall();   // C version
> void axisDestroyCall(AXISHANDLE call);   // C version
> So a create function allocates storage that the application is 
> expected to free with a matching destroy function. A "get" function 
> returns storage that the user should not free (except if the 
> returned data is a C-style string which is a strdup'ed copy).

> C functions that map to overloaded methods will have the superset of 
> all the parameters on the overloaded methods. The application will 
> then have the option of passing NULL for parameters that it does not 
> wish to pass in. So...
> IAttribute* IHeaderBlock::createAttribute(const AxisChar* localname, 
> const AxisChar* prefix, const AxisChar *uri, const AxisChar *value); 
> // C++ version IAttribute* IHeaderBlock::createAttribute(const 
> AxisChar* localname, const AxisChar* prefix, const AxisChar *value); 
> // C++ version AXISHANDLE axisCreateAttribute(AXISHANDLE headerBlock,
>  const AxisChar* localname, const AxisChar* prefix, const AxisChar 
> *uri, const AxisChar *value); // C version
> and applications can pass a NULL uri if so desired. Where the same method
> occurs on multiple classes, the C function names will contain the relevant
> class names to distinguish them. So...
> BasicNode* BasicNode::getChild(int position);  // C++ version
> BasicNode* IHeaderBlock::getChild(int position);  // C++ version
> AXISHANDLE axisGetChildFromBasicNode(AXISHANDLE basicNode, int 
> position); // C version AXISHANDLE 
> axisGetChildFromHeaderBlock(AXISHANDLE headerBlock, int position); 
> // C version
Yes such a convention is needed. This one is ok

> There may be methods/functions where it is not clear whether it is 
> up to Axis or the application to free the storage. I will attempt to 
> identify these and clarify who owns the storage by sensible naming 
> of methods/functions and by providing API documentation. If I 
> discover any public data, I will eliminate it from classes which are 
> external to Axis C++ and I will provide C functions to access data,
>  rather than returning structs containing public data for the 
> application to free.
> My intention is to provide in the external headers only those
> functions/methods which are tested, working and useful to 
> applications and to internalise all others by moving them to src/.



> Apologies for the long note but I'd rather discuss this openly 
> before I implement it so that people can comment on it. So ... any comments?
> Mark
> Mark Whitlock

Damitha Kumarage
hSenid Software International (PVT) Ltd

Lanka Software Foundation (

View raw message