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 Mark Whitlock <ma...@uk.ibm.com> on 2004/10/06 13:58:38 UTC
More C/C++ support
Hi,
Is it OK to pass STL strings, lists, etc across the external client API? I
remember that this was frowned upon.
So there's several methods on Call and IWrapperSoapDeserializer like
getElementAsString which return a strdup'ed C-style string that the
application has to free.
When making the engine pure C++, I would prefer these changed to using STL
strings. Else these could change to a new char[].
Most parts of the external client API assume that the application should
delete the returned storage (such as Call::getElementAsString and many
others) but other methods (such as ISoapFault::getFaultcode) delete the
storage in ~SoapFault. This isn't a memory leak as such, but it does make
it very easy to write applications with memory leaks. I propose that
(wherever possible) it should be up to the application to delete the
storage for strings returned from these methods, and the documentation for
all methods that return strings or other data, should say whose
responsibility it is to delete the storage.
Mark
Mark Whitlock
IBM
Re: More C/C++ support
Posted by John Hawkins <HA...@uk.ibm.com>.
Although I agree whole heartedly that STl should be the way to go becuase
it is object based and a "standard". Fundamentally it isn't living up to
what it's meant to do i.e. be a standard. There are different
implementations for different platforms that are causing people in large
environments big problems. This pushes me to say STL is bad and we should
move away from it. As much as I hate to say that we should use char* over
an Object :-(
John Hawkins
Samisa Abeysinghe
<samisa_abeysingh
e@yahoo.com> To
Apache AXIS C Developers List
06/10/2004 13:40 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C Re: More C/C++ support
Developers List"
There are mixed imotions on the use of STL.
There has been much discussion on this.
http://marc.theaimsgroup.com/?t=109279386800002&r=1&w=2
Has few thoughts on why we should be leaving out STL.
Jira AXISCPP-61 has some info on STL map related memory leaks.
And few discussions on that
http://marc.theaimsgroup.com/?t=108192149500002&r=1&w=2
http://marc.theaimsgroup.com/?t=108988810300003&r=1&w=2
Alek thinks we should be using STL more.
Alexei too think so
http://marc.theaimsgroup.com/?l=axis-c-dev&m=109682030315422&w=2 (have a
look
at the bottom)
http://marc.theaimsgroup.com/?t=108381431500005&r=1&w=2
A discussion thread on eliminating STL
After all, I think we need to objectively measure (both for speed and
space) STL sting vs. char*.
I think for performance we should be using char* and let the user clean up.
I do not think much of the operations in STL string class would be usefull
in serialization,
deserialization. It comes as bytes; and it is simpler to give away as char*
Simply speaking I am for char* :-)
Thanks,
Samisa...
--- Mark Whitlock <ma...@uk.ibm.com> wrote:
>
>
>
>
> Hi,
> Is it OK to pass STL strings, lists, etc across the external client API?
I
> remember that this was frowned upon.
>
> So there's several methods on Call and IWrapperSoapDeserializer like
> getElementAsString which return a strdup'ed C-style string that the
> application has to free.
> When making the engine pure C++, I would prefer these changed to using
STL
> strings. Else these could change to a new char[].
>
> Most parts of the external client API assume that the application should
> delete the returned storage (such as Call::getElementAsString and many
> others) but other methods (such as ISoapFault::getFaultcode) delete the
> storage in ~SoapFault. This isn't a memory leak as such, but it does make
> it very easy to write applications with memory leaks. I propose that
> (wherever possible) it should be up to the application to delete the
> storage for strings returned from these methods, and the documentation
for
> all methods that return strings or other data, should say whose
> responsibility it is to delete the storage.
>
> Mark
> Mark Whitlock
> IBM
>
>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Re: More C/C++ support
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
There are mixed imotions on the use of STL.
There has been much discussion on this.
http://marc.theaimsgroup.com/?t=109279386800002&r=1&w=2
Has few thoughts on why we should be leaving out STL.
Jira AXISCPP-61 has some info on STL map related memory leaks.
And few discussions on that http://marc.theaimsgroup.com/?t=108192149500002&r=1&w=2
http://marc.theaimsgroup.com/?t=108988810300003&r=1&w=2
Alek thinks we should be using STL more.
Alexei too think so http://marc.theaimsgroup.com/?l=axis-c-dev&m=109682030315422&w=2 (have a look
at the bottom)
http://marc.theaimsgroup.com/?t=108381431500005&r=1&w=2
A discussion thread on eliminating STL
After all, I think we need to objectively measure (both for speed and space) STL sting vs. char*.
I think for performance we should be using char* and let the user clean up.
I do not think much of the operations in STL string class would be usefull in serialization,
deserialization. It comes as bytes; and it is simpler to give away as char*
Simply speaking I am for char* :-)
Thanks,
Samisa...
--- Mark Whitlock <ma...@uk.ibm.com> wrote:
>
>
>
>
> Hi,
> Is it OK to pass STL strings, lists, etc across the external client API? I
> remember that this was frowned upon.
>
> So there's several methods on Call and IWrapperSoapDeserializer like
> getElementAsString which return a strdup'ed C-style string that the
> application has to free.
> When making the engine pure C++, I would prefer these changed to using STL
> strings. Else these could change to a new char[].
>
> Most parts of the external client API assume that the application should
> delete the returned storage (such as Call::getElementAsString and many
> others) but other methods (such as ISoapFault::getFaultcode) delete the
> storage in ~SoapFault. This isn't a memory leak as such, but it does make
> it very easy to write applications with memory leaks. I propose that
> (wherever possible) it should be up to the application to delete the
> storage for strings returned from these methods, and the documentation for
> all methods that return strings or other data, should say whose
> responsibility it is to delete the storage.
>
> Mark
> Mark Whitlock
> IBM
>
>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com