CBSTR StringBuilder Class

[José Roca]

I have added a constructor and an overloaded operator to allow to assign directly a CWSTR to a CBSTR.

Now we can use cbs = cws instead of cbs = cws.Str

Thanks to Marc for helping me in a detail that I was missing about forward references of types.

[Johan Klassen]

thank you Jose Roca
is this your latest version ? http://www.planetsquires.com/protect/forum/index.php?topic=3892.msg28913#msg28913

[José Roca]

No. I'm still working on it.

[Johan Klassen]

ok

[José Roca]

Got it. I was having a problem with returning a CWSTR. It was working without problems if the return type was declared AS CBSTR, but if declared AS CWSTR it GPFd because the pointer of the copy was the same that the CWSTR that was going to be destroyed. So I was getting a dangling pointer.

The solution has been to add an overloaded LET operator in which I force the creation of a new buffer in which I copy the string data by calling the ResizeBuffer function.

Code Select Expand


' ========================================================================================
OPERATOR CWstr.Let (BYREF cws AS CWStr)
   IF m_pBuffer = cws.m_pBuffer THEN EXIT OPERATOR   ' // Ignore cws = cws
   this.Clear
   this.ResizeBuffer(LEN(cws))
   this.Add(cws)
END OPERATOR
' ========================================================================================


The new CWSTR type is so fast that I doubt that you will need to have an ansi version of the string procedures.

Only using FB strings and s += "<some text>" is faster, about twice, probably because it has to copy half the bytes that CWSTR, which is unicode. Guess that if FB has a dynamic unicode string it won't be faster.

Test of speed in my computer:

FB ansi strings:

100,000 appends -> 26 ms
500,000 appends -> 144 ms
1,000,000 appends -> 294 ms

CWSTR strings:

100,000 appends -> 53 ms
500,000 appends -> 280 ms
1,000,000 appends -> 563 ms

[José Roca]

We have started writing a class intended to add speed to CBSTR and have ended with a superfast dynamic null terminated unicode data type that replaces CBSTR for most uses except COM. Not bad!

I'm going to change the name of the include file from CBSTR.inc to CWSTR.inc because WSTR can mean wide string, and both data types are wide string, whereas BSTR is associated with the strings used by VB and COM and have the bad repuration of being slow.

[James Fuller]

The new CWSTR type is so fast that I doubt that you will need to have an ansi version of the string procedures.
1,000,000 appends -> 563 ms

It's not about speed. I need them for parsing ansi text files. I do not use unicode for File IO.

James

[José Roca]

You can pass ansi strings to the unicode functions, whereas if you do the opposite they will be converted to garbage if they don't use the Latin alphabet.