In reviewing a proposed patch from Raymond, I was reminded that I keep
meaning to propose a change to UtlString that will reduce the need for a
number of data copies (sometimes large ones).

The primitive I'd like to add is one to directly set the length of the
data in the buffer; we already have a method to get the pointer to the
buffer (UtlString::data), so it's possible to get that pointer and write
to it, and we have a method to ensure that the buffer can hold a given
size (UtlString::capacity).  All that's missing is a way to directly
write content into the buffer and then after the fact tell the UtlString
how much data you put there.  There are many places in the code now
where we create an intermediate variable (sometimes a big one) that we
can write into just so that we can then copy it again using one of the
append methods of UtlString.

Here's the description I propose:

        void
        setLength 
        (
        size_t 
        newLength 
         ) 
        
                Set a new length for the content. 
                
                This does NOT modify the data in the buffer - it only
                resets the value that would be returned by
                UtlString::length. The newLength value MUST be <=
                UtlString::capacity.
                
                This allows external code to directly manipulate the
                contents of buffer and adjust the UtlString data
                accordingly. For example, the following sets the
                'buffer' to contain a 'sizeNeeded' number of bytes of
                all one bits: 
                
                
                UtlString buffer;
                if (buffer.capacity(sizeNeeded) >= sizeNeeded)
                {
                   memset(buffer.data(), 0xff, sizeNeeded);
                   buffer.setLength(sizeNeeded);
                }


        
        
        
        
        
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to