axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hawkins <>
Subject Re: More C/C++ support
Date Wed, 06 Oct 2004 13:57:36 GMT

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                                             
   >                                               To 
                                       Apache AXIS C Developers List       
             06/10/2004 13:40          <>          
             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.
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
Alek thinks we should be using STL more.
Alexei too think so (have a
at the bottom)
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* :-)


--- Mark Whitlock <> wrote:

> Hi,
> Is it OK to pass STL strings, lists, etc across the external client API?
> 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
> 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
> all methods that return strings or other data, should say whose
> responsibility it is to delete the storage.
> Mark
> Mark Whitlock

Do you Yahoo!?
Declare Yourself - Register online to vote today!

View raw message