[omniORB] strings versus char arrays

[Duncan Grisby]

On Tuesday 17 September, Wilson Jimmy - jiwils wrote:

> There is an ongoing debate where I work on whether or not to use the CORBA
> string IDL type or a NULL terminated character array in some instances.

Yuck...

> Ultimately, memory is going to be allocated regardless of the type used
> right?  In the string case, the programmer can have explicit control over
> the allocation/deallocation of memory, but with the character array, isn't
> the ORB doing a new underneath as well?  Given that, is any more time spent
> doing memory housekeeping with one or the other?

There are a few cases with a char array where the array is on the
stack, rather than dynamically allocated, so you would save a tiny
tiny amount of time. However, there are lots of situations where
arrays have to be heap allocated, so it's not a big deal.

However, a bigger issue is that with an ORB that supports code set
negotiation (omniORB 4, for example), marshalling an array of chars
will be slower than a string since each char is dealt with separately,
rather than together as a string, and worse, the negotiated code set
encoding may mean that some characters cannot be represented in the
marshalled array.

An example of this is an omniORB 4 client talking to a Java server.
The Java ORB will specify UTF-8 as its preferred char code set. If the
"string" you are transmitting as a char array contains any ISO-8859-1
characters like accented letters, the UTF-8 representation of them
takes two bytes. Marshalling them as individual chars in an array
means the data cannot be sent, and you get DATA_CONVERSION exceptions.

A bad idea all round.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --