axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <>
Subject Re: Fw: C and C++ support
Date Fri, 01 Oct 2004 04:45:22 GMT
Hi Mark,
    This is a well thought approach. I havde added few of my thoughts below.

--- Mark Whitlock <> wrote:

> Hi,
> I agree. Convert the engine to pure C++, fix memory leaks and remove C
> support for 1.4 and in 1.5 put C support back in as a wrapper layer.
> Before the C support gets disabled in 1.4, it would be good to understand
> what the C support should look like in 1.5. We should support
> generated C stubs, and C services. I think we should continue support the
> "dynamic" client API, whereby applications can construct their own Call
> object to invoke a service, without using generated stubs. I propose we
> don't add in C support for handlers, unless anyone raises a requirement.

One of the key problems is what data structures should be used when supporting C in 1.5. If
make the engine return a C++ object in case of arrays, how should we wrapp and present it
to C
In a pure C++ implementation, I would like to return Class objects, with destructus to take
of memory.
When such an object is wrapped for C, we most probably have to return a C struct, crated out
the C++ class object. And we have to provide wrapper methods to take care of memory.

> Most of this C support for the "dynamic" client API is currently in header
> files, but that which is source files could be separated out into separate
> source files so as to distinguish the C bindings from the engine. The C
> bindings in the header files could be split out into separate header files,
> .hpp files for C++ and .h files for C. So a C++ application would include
> Call.hpp and a C application would include Call.h. 

+1. The current code where all C++ and C code is in the same file is a headache when it comes
code maintanance. This seperation would allow us to better manage the code.

> But that would mean all existing C++ applications changing. 

True. An alternative would be to keep the existing headers as is for C++ and add a folder
for C stuff - e.g. c/Call.h.
However, if changing existing apps is not that much of a concern for users, I would preffer
vs .h semantics.

> Also the C binding source files
> could be linked into a separate dll/shared library. How far do people think
> the C bindings should be separated out from the C++ engine?

I think C binding should be completely seperated from the C++ engine. 

> Using this "dynamic" client API today from C is awkward since applications
> would have write code such as ...
> Call *pCall = (Call*)getStubObject(APTHTTP, uri);
> pCall->_functions->setTransportProperty(pCall->_object, SOAPACTION_HEADER,
> "Calculator#add");
> pCall->_functions->setOperation(pCall->_object, "add",
> "http://localhost/axis/Calculator);
> pCall->_functions->addParameter(pCall->_object, &i1, "in0",XSD_INT);
> pCall->_functions->addParameter(pCall->_object, &i2, "in1",XSD_INT);
> pCall->_functions->invoke(pCall->_object);
> which is the kind of code that wsdl2ws generates now. A more natural
> programming model for C would be ...
> Call *pCall = axiscGetStubObject(APTHTTP, uri);
> axiscSetTransportProperty(pCall,SOAPACTION_HEADER, "Calculator#add");
> axiscSetOperation(pCall, "add", "http://localhost/axis/Calculator);
> axiscAddParameter(pCall, &i1, "in0",XSD_INT);
> axiscAddParameter(pCall, &i2, "in1",XSD_INT);
> axiscInvoke(pCall);

> Wsdl2ws could generate C stubs on top of the "dynamic" client API C
> bindings or it could generate a C binding on top of the
> generated C++ stubs. Either way, currently the generated C stubs contain
> functions called by the operation name. So the
> Calculator sample generates a C function called int add(void* pStub, int
> value0, int value1). Such functions could easily nameclash,
> so I propose the generated C function names should be
> <portname>_<operationname>. So the Calculator sample would
> generate C functions like int Calculator_add(void* pStub, int value0, int
> value1).

Yes, it is a good idea to prevent name clashes (can we use C style all simples here? e.g.
But I have doubts on how appropriate it would be to pass the first arg here; why do we need
pStub" as the first param? Can't the generated code handle this for user?
In other words can we make it look like:
calculator_add(int value0, int value1);
which is more natural C style

> As an aside, I should investigate whether wsdl2ws uses the servicename or
> the portname for the generated C++ class. I think
> the portname should be used here since the soap:address is burnt into the
> stub so the generated stub is port-specific not
> service-specific.

Good idea!

> It would be good to agree what direction we are going in with the C
> bindings, before the existing C bindings get removed/disabled
> for 1.4, since then we will know how much needs completely removing and
> rewriting and how much could be disabled and
> reenabled in 1.5.

Yes, we may use a mock up sample and try to establish how C++ and C gerated stuff look like.
(We can use the calculator sample that you have used)
This would help us visualize what we have in our minds and also asses the feasibility; specially
the problems related to data structures in C and C++.

Additionally, I would like to propose that we use a deep copy based implementations for internal
classes, with assignment operators and copy constructors. (e.g for BasicNode class)
In order to gaurentee efficincy/ prevent memory duplication, we can lay out few best practices
such  as passing const refs as prameters, returning pointers to objects, ref count mechanisms

For objects returned to C++ stubs, I would like them returned as pointers, instead of by value
(current model returns objects by value). In case of return by value, I think it is a must
that we
overload assignment operator with deep copy or ref count.


> Mark
> Mark Whitlock
> ----- Forwarded by Mark Whitlock/UK/IBM on 30/09/2004 15:41 -----
>              John                                                          
>              Hawkins/UK/IBM@IB                                             
>              MGB                                                        To 
>              30/09/2004 12:09                                           cc 
>                              , Apache    
>                                        AXIS C User List                    
>              Please respond to         <>         
>               "Apache AXIS C                                       Subject 
>                 User List"             Re: C and C++ support               
> Yep - we thought of that already :-)
> We're going to set up some server tests to ensure that we don't screw it
> up.
> John Hawkins
>              Samisa Abeysinghe
>              <samisa_abeysingh
>    >                                               To
>                                        Apache AXIS C User List
>              30/09/2004 11:10          <>,
>                                                                         cc
>              Please respond to
>               "Apache AXIS C                                       Subject
>              Developers List"          Re: C and C++ support
> Hi All,
>    One of the possible problems of converting the engine to pure C++ is
> that, one would have to
> keep an eye on both the client side as well as the server side, while the
> refactoring is going on.
> So it would be necessary to have both client side as well as server side
> test cases in place
> before we start on this task. (a typical refactoring scenario) I think we
> can manage with whatever
> tests we have at the moment.
>    As long as we keep on testing client and server in parallel, we would be
> able to achieve
> success with this task.
> Thanks,
> Samisa...
> --- John Hawkins <> wrote:
> >
> >
> >
> >
> > Hi Folks,
> >
> > Throughout the last year we have come across many problems related to our
> > continued commitment to supporting both C and C++ stubs. The design of
> the
> > engine code has been greatly affected by this and has caused quite a few
> > problems particularly with regard to memory management. Please see here
> > and here
> > for some of the issues
> we
> > have recently uncovered.
> >
> > The reasoning behind supporting C is clear - to support legacy
> > applications. We have had the debate about using C internally for
> > performance reasons and I think we have concluded that we need to get the
> > code stable and then consider performance. The intermingling of C and C++
> > in the core code has created more problems than it would appear to have
> > solved (Current performance charts show azis C looking very bad).
> >
> > In order to improve and stabilise the code I would like to propose that
> we
> > remove C structures, memory allocation etc. such that we have a 100% C++
> > engine. If we did this we can then enhance WSDL2WS such that it creates C
> > wrappers for the pure C++ code. There is, in my opinion,  no question
> that
> > this will improve the quality of the code - particularly memory
> management.
> >
> > If this is agreed upon then I would like to propose that we take a two
> > staged approach in the management of this change. I would like us to
> > withdraw C support for the NEXT RELEASE ONLY (1.4). In 1.4 we can work on
> > making the engine 100% C++. I would then like us to reintroduce the C
> > support in the post 1.4 timeframe (1.5) by making the changes to WSDL2WS.
> >
> > This approach enables us to concentrate on improving the core engine code
> > in the first instance without worrying about updating the C support in
> > WSDL2WS - code that will get changed in the next release. Once we have
> > proven that we have a stable 100% C++ engine we can then concentrate
> > entirely on C support - i.e. by producing the nicely encapsulated
> > wrappering layer.
> >
> >
> > I hope that we, as a community, can work through this problem quickly so
> > that we can make the core code more stable and C support of a much higher
> > quality. I look forward to your responses.
> >
=== message truncated ===

Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages! 

View raw message