axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hawkins <>
Subject Re: Generating C stubs
Date Fri, 10 Dec 2004 10:00:18 GMT

Some comments below.

Overall, I think that we should go with the C to C option and avoid going
through the C++ layer. It looks too error prone. The only bonus, as far as
I can tell,  of going through the C++ stubs is that WSDL2WS gets simplified
but we can still do more refactoring on WSDL2Ws to aid this.

John Hawkins

Mark Whitlock/UK/IBM@IBMGB wrote on 09/12/2004 15:43:22:

> Hi,
> I'm investigating how to generate the C client stubs. There are two
> approaches....
> - Change WSDL2Ws so that it generates C stubs to the new dynamic C client
> API.
> - Generate the C stubs as a thin layer on top of the C++ stubs. This
> be done using the logic from the C binding generator tool that I'm
> currently developing, driven from WSDL2Ws.
> Paul Fremantle suggested the second approach and I'm weighing up the two
> alternatives. Most fixes to WSDL2Ws need to be copied to 4 places: C
> rpcenc, C doclit, C++ rpcenc and C++ doclit which is error prone. The
> advantage to the generated C stubs calling the generated C++ stubs is
> it removed this duplication in WSDL2Ws. Here are some thoughts on
> C stubs calling the generated C++ stubs, instead of the dynamic C API....
> - Client applications that use generated stubs can also use the dynamic
> client API. Generated stubs inherit methods that allow getting and
> of headerblocks, attributes, etc. If generated C stubs call the generated
> C++ stubs, C applications would have to link with the dynamic C++ API as
> well as the dynamic C API. This is ok as long as C++ object instances are
> mapped to C handles in the same way in the generated C stubs as in the
> dynamic C API.
> - Complex types are represented by classes in C++ but by structs in C. If
> the underlying generated C++ stub (de)serializes classes and the
> C stub casts these classes to structs, it relies on these generated
> and structs having the same length and field offsets for all compilers on
> all platforms. I tried this on Windows using MS Visual C++ and they were
> the same length. Can we rely on this? The alternative approach of
> C stubs calling the dynamic C API does not rely on this.
> - Arrays are represented as structs in C and classes in C++ as these also
> contain the array's length. The C++ implementation should have other
> methods that overload operator[ ] and delete the array storage in the
> destructor. For C++, a better implementation might be to use a template
> avoiding duplicated code for arrays of different types. Now the C and C++
> representations really would be different and a C stub could not rely on
> C++ stub to generate such an array for use in C.

Not sure that templates are a good thing. I *believe* that templates are
supported differently on different compilers?

> - Generated stubs (C++ stubs and the old C stubs) do not deallocate
> for output or return parameters. It is up to the application to
> the storage when appropriate. Storage for output complex objects is
> allocated in a callback function AXIS_OBJECT_CREATE_FUNCT. So WSDL2Ws
> generates an implementation of AXIS_OBJECT_CREATE_FUNCT which the client
> engine calls when it needs to allocate storage for an output complex
> object. If the generated C stubs call the generated C++ stubs, it will be
> the generated C++ callback which allocates storage using new (not
> Later on the C application will have to attempt to free this storage
> free(). Instead the generated C stubs would have to generate their own
> callbacks which use malloc/free and then pass them into the generated C++
> stubs using an extra private API.
> - There are some places where generated C++ stubs allocate storage using
> new, for instance in allocating an output array of primitives. Instead
> generated C++ stubs would have to be aware that they were being called
> a generated C stub and use malloc instead.

Oh Yuck ! how complex is this going to be in WSDL2Ws? This sounds like the
straw that could break the Camels back to me !

> - I haven't investigated how this would work for C services. Following
> model, the Axis server would call a generated C++ skeleton which would
> a generated C skeleton which would call the application code. I am not
> sufficiently familiar with the server to know if this would work.
> - C applications would have to be compiled with a C++ compiler if their
> generated C stubs called generated C++ stubs.

Not a big issue ? Or would this affect people if we (they) are thinking
about porting this to a pervasive device?
> Generated C stubs calling generated C++ stubs is the best approach if...
> - Users don't mind compiling their C code with a C++ compiler
> - Classes and their corresponding structs are always the same length for
> every compiler on every platform
> - The tool that generates the C stubs is decoupled from WSDL2Ws (although
> called by it), so that it doesn't break every time changes are made to
> - The generated C++ artifacts can be encapsulated within the generated C
> artifacts so avoiding any confusion
> - The server's generated C skeletons can be made to work in a similar way
> Generated C stubs calling the dynamic C API is the best approach if...
> - WSDL2Ws could be refactored so every change does not have to be made to
> the C and C++ support separately
> Comments?
> Mark
> Mark Whitlock

View raw message