>>Gregory,
>>
>>>In a right to left you never move a char too many, ie one that you will discard later, you move processed data
>>>
>>>In a left to right you are likely to move chars that you will discard later, you move non processed data
>>
>>One of Fabio's first posts talked about O(k*n*n) which is basically the algorithm that chrtran uses now, it's performance is bad because the whole rest of the string is slid left one position. Which means the the same character gets moved more than once. Now if the string is processed right to left, but the whole rest of the string is slid right one position the result is the same bad performance.
>
>Anyone can see that moving a char once it the best solution
>
>Fabio's point was that right to left outperforms left to right
>
>>
>>Processing right to left, along with the same sort of move optimization that is in my C++ code does improve over the native chrtran() but it's no faster than my C+ code. it's actually a little worse because of having to deal with moving the start of string.
>>
>>For easier reference, here the C++ code:
>>
>>

>>int CDequoteApp::DeQuote(int nBufferLength, LPSTR cBuffer)
>>{
>>char *cpIn;
>>char *cpOut;
>>
>>cpIn = cBuffer; // start both pointers at the beginning of the buffer
>>cpOut = cpIn;
>>
>>for ( int i = 0; i < nBufferLength; i++, cpIn++ )
>>   {
>>   if ( *cpIn != '"' )  // that's a " inside two '
>>      *cpOut++ = *cpIn; // copy the character and advance the output pointer
>>   }
>>
>>return ( cpOut - cBuffer );
>>}
>>

>>
>>>Left >> right = move chars that will not necessarily be in the end result
>>
>>The best objective is to never move a characer that is not in the result, and never move a character more than once.
>>
>>>eg: take * out
>>>
>>>12*4*6*89
>>>
>>>Left >> right
>>>move 1: 4*6*89 6 chars where 2 not in the end result
>>>move 2: 6*89 4 chars where 1 not in the end result
>>>move 3: 89 2 chars where 0 not in the end result
>>> ---
>>> 12 chars where 3 not in the end result
>>
>>No, with left to right it can in fact be done with only 6 characters "moved" although 2 of them are moved to the same place. And we never move an *. Here's what the buffer looks like for each of the nine steps (the underlined tex represents the output text at each step):
>>
>>12*4*6*89 && 1 moved to 1st position
>>12*4*6*89 && 2 moved to 2nd position
>>12*4*6*89 && nothing moved because 3rd char is *
>>1244*6*89 && 4 moved to 3rd position
>>1244*6*89 && nothing moved because 5th char is *
>>1246*6*89 && 6 moved to 4th position
>>1246*6*89 && nothing moved because 7th char is *
>>124686*89 && 8 moved to 5th position
>>124689*89 && 9 moved to 6th position, and we return the fact that the output string is 6 characters long.
>>
>>so the task is accomplished with 6 moves, which is only 2/3 of what your right to left processing does below:
>>
>>>Right to left
>>>
>>

>>>move 1: 89       2 chars where 0 not in the end result
>>>move 2: 689      3 chars where 0 not in the end result
>>>move 3: 4689     4 chars where 0 not in the end result
>>>                ---
>>>                 9 chars where 0 not in the end result
>>

Hi Gregory,

you must have one infinite patience!
With David it is like running on orthogonal roads,
happens that these are intercrossed but not there is communication.

Fabio