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 15:23:53 GMT




Hi Samisa,
Thank you for your comments. I think we are in general agreement and making
good progress.

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

I too would prefer separate .h and .hpp files so I'll rename the current
external .h files to .hpp (when I have removed the C bindings from them)
and create new .h files which will just contain the C bindings.

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

I propose that wsdl2ws continues to generate C stubs which call the C
bindings for the "dynamic" API.

We agree about the names of these generated C stub functions, but there are
times when the stub does need to be passed as the first parameter. The
client application may have created several client stubs and be
interleaving calls to each of them. Then the client really does need to
know which stub instance they are issuing the request for. This is clearer
for a stateful web service. WSIF (and Axis Java?) has an AddressBook sample
where an application can create an AddressBook, add names to it and query
names in it. I agree simple applications would rather issue
calculator_add(int value0, int value1); so maybe we could also have
calculator_add_instance(Stub* pStub, int value0, int value1); (but
calculator_add_instance isn't a very good name). What do you think? This
problem doesn't happen for C++, of course.

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

What you're proposing sounds good, but I don't fully understand it. Which
classes does this affect? Is this only an internal change, or external as
well? Is this just to improve class design, or are you aware of memory
leaks/problems that this would fix?

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

Are you suggesting return by pointer to reduce copying of objects, and
therefore improve performance, or are there other reasons as well? I tried
the SimpleArray sample and that returns a pointer to the array, so I'm
confused about when objects are returned by value, and when by reference.

As a side issue I'd like to find out the C++ external API so I could see
how it manages storage and verify the C external API is the same. I've
found __declspec(dllexport) and __stdcall on certain classes/methods.
__stdcall seems to be on methods/functions that are externalised to the
client application. Methods externalised to handlers are not marked in
anyway apparently as all handlers need to if (pIMsg->isPastPivot()) and yet
isPastPivot() is declared in the same way as every other internal public
method. What exactly do __stdcall and __declspec(dllexport) do, and why are
they not needed on handler APIs?

Thanks,
Mark
Mark Whitlock
IBM

----- Forwarded by Mark Whitlock/UK/IBM on 04/10/2004 15:13 -----
                                                                           
             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