axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hawkins <>
Subject Re: Encoding support - [WAS] RE: STL elimination - Suggestions
Date Fri, 07 May 2004 12:14:03 GMT

could icu4c help us with unicode issues here?

John Hawkins,

             "Susantha Kumara"                                             
   >                                                    To 
                                       "'Apache AXIS C Developers List'"   
             07/05/2004 06:19          <>          
             Please respond to                                     Subject 
              "Apache AXIS C           Encoding support - [WAS] RE: STL    
             Developers List"          elimination - Suggestions           

Hi Lilantha,

>-----Original Message-----
>From: Lilantha Darshana []
>Sent: Friday, May 07, 2004 4:11 AM
>To: 'Apache AXIS C Developers List'
>Subject: RE: STL elimination - Suggestions
>I would suggestion at this point going for w_char * for strings
handling to
>Unicode char-sets.

What I have in mind is to make it a compile time decision whether Axis
uses utf-8 or utf-16. So Axis can be built in either ways. But this
doesn't mean that Axis receives the other encoding. It is the
responsibility of the XML parser to transcode the XML data to the
encoding that Axis has been built.

ie: if UTF8 build of Axis receives a message in UTF16, the XML parser
should transcode the data to UTF8. But all messges sent out will always
be in UTF8.

ie: if UTF16 build of Axis receives a message in UTF8, the XML parser
should transcode the data to UTF16. But all messges sent out will always
be in UTF16.

I think this is ok because WS-I profile says,

"while a sender might choose whether to encode XML in UTF-8 or UTF-16
when sending a message, a receiver must be capable of using either"

In order to do this we have to define a AxisChar so that compiler
directive will decide whether AxisChar is char(8-bit) or short(16-bit).
This means that we have to have all string manipulation functions like
strcmp, strcpy etc that can be used with either char or short strings.
To solve this problem we might be able to use some existing opensource
tool kits rather than writing our own set of functions to replace
strcmp, strcpy, strcat etc.


>Think twice when you replace std::string with your impl. of a String
>Do a performance
>comparison and usability study. Your class should out perform
std::string in
>the context
>you use. o/w stick with std::string.
>Writing your own Map class is also the same -- std::map impl. uses best
>algorithms available
>today. hence, If you go for your impl. you should think twice. -- if it
>possible to replace
>key/value lookup with index/value lookup then just go for using an
>o/w its an overkill.
>and harder to use. void pointer casting require some more instruction
>it's machine code.
>But compile time binding does not involve any additional instruction in
>object code.
>But if you could make your code simple and avoid using std::maps,
>really improves the
>performance. Iff simple C code/algo can do the same task.
>But f we can avoid using following in most of the cases if you know the
>of the collection
>before hand. by using a simple array.
>-----Original Message-----
>From: Susantha Kumara []
>Sent: Wednesday, May 05, 2004 11:30 PM
>To: axis-c-dev
>Subject: STL elimination - Suggestions
>Hi all,
>I would suggest following order and steps to gradually eliminate STL in
>C++ codebase.
>Use "char*" instead of "string" wherever possible - need to take care
of the
>memory allocation and deallocation
>Write our own String class to replace the strings left after step 1.
>Review the code base and minimize the use of std::map's functions.
>std::map with arrays or lists where possible
>Write our own Map class with minimum functionality and use it in yet
>existing places after step 1. Even if we don't use templates to write
>map class we can make this almost generic if we use a class which has
>void* for key
>void* for value
>allocator/deallocator provided externally
>key comparison function provided externally
>Probably we can use linked lists to replace these.

View raw message