axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Whitlock <mark_whitl...@uk.ibm.com>
Subject Fw: C and C++ support
Date Mon, 04 Oct 2004 09:31:10 GMT




Hi,
I will move all the C support from the head of the stream into a new "C
bindings sandpit" branch soon now. So the head will not contain any C
bindings for 1.4. Then in 1.5 I'll merge the reworked C bindings back into
the head.
Mark
Mark Whitlock
IBM

----- Forwarded by Mark Whitlock/UK/IBM on 04/10/2004 10:25 -----
                                                                           
             John                                                          
             Hawkins/UK/IBM@IB                                             
             MGB                                                        To 
                                       "Apache AXIS C Developers List"     
             01/10/2004 13:33          <axis-c-dev@ws.apache.org>          
                                                                        cc 
                                                                           
             Please respond to                                     Subject 
              "Apache AXIS C           Re: Fw: C and C++ support           
             Developers List"                                              
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           








> 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 to
code maintanance. This seperation would allow us to better manage the code.

+1 from me !


> 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.

+1 from me !



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++.


+1 !



John Hawkins





             Samisa Abeysinghe
             <samisa_abeysingh
             e@yahoo.com>                                               To
                                       Apache AXIS C Developers List
             01/10/2004 05:45          <axis-c-dev@ws.apache.org>
                                                                        cc

             Please respond to                                     Subject
              "Apache AXIS C           Re: Fw: C and C++ support
             Developers List"









Hi Mark,
    This is a well thought approach. I havde added few of my thoughts
below.

--- Mark Whitlock <mark_whitlock@uk.ibm.com> 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 we
make the engine return a C++ object in case of arrays, how should we wrapp
and present it to C
stub?
In a pure C++ implementation, I would like to return Class objects, with
destructus to take care
of memory.
When such an object is wrapped for C, we most probably have to return a C
struct, crated out of
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 to
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 prefix
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 .hpp
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);
+1.

>
> 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.
calculator_add)
But I have doubts on how appropriate it would be to pass the first arg
here; why do we need "void*
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 etc.


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.

Thanks,
Samisa...


>
> Mark
> Mark Whitlock
> IBM
>
> ----- 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
>                                        axis-c-dev@ws.apache.org, Apache

>                                        AXIS C User List

>              Please respond to         <axis-c-user@ws.apache.org>

>               "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
>              e@yahoo.com>
To
>                                        Apache AXIS C User List
>              30/09/2004 11:10          <axis-c-user@ws.apache.org>,
>                                        axis-c-dev@ws.apache.org
>
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 <HAWKINSJ@uk.ibm.com> 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
> > http://marc.theaimsgroup.com/?l=axis-c-dev&m=109461822722177&w=2 and
here
> > http://nagoya.apache.org/jira/browse/AXISCPP-149 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!
http://promotions.yahoo.com/new_mail




Mime
View raw message