You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Samisa Abeysinghe <sa...@yahoo.com> on 2004/10/01 06:45:22 UTC
Re: Fw: C and C++ support
Hi Mark,
This is a well thought approach. I havde added few of my thoughts below.
--- Mark Whitlock <ma...@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 <ax...@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 <ax...@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 <HA...@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
Re: Fw: C and C++ support
Posted by John Hawkins <HA...@uk.ibm.com>.
> 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 <ax...@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 <ma...@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 <ax...@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 <ax...@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 <HA...@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