Paul,
As the other topic veered off course .....
Will you be updating your FF_xxxx string routines or is my composite library ok?
I do not intend to use unicode for file IO as ascii is still the predominant format.
I want to be able to read output with other utilities and most only support ascii.
I will probably do a tweak here and there and possibly a renaming???
James
Hi James,
I haven't really thought about it much but right now my intention is to use Jose's AfxStr versions of those FF string routines. I haven't tried them with straight ansi strings yet so maybe overloaded versions may be needed, or, simply continue with the ansi versions as well. Like I said, I haven't really thought about it much. :)
On second thought they probably should be overloaded AfxStr functions to keep everything uniform.
Are you in agreement Jose. Just a few more items to add to AfxStr :)
James
Just wait for the next release candidate that I will post soon.
Thanks to an small change suggested by Marc, appending strings with CWSTR has become even faster that using FB native strings!
And with a growing size of 260 * 2 bytes (the size of max path in unicode), instead of 16 kb.
#include once "Afx/CBStr.inc"
#Include Once "crt/time.bi"
using Afx
dim z1 as double
dim z2 as double
z1 = clock()
DIM i AS LONG
DIM s AS STRING
FOR i = 1 TO 1000000
s &= "Paul Squires"
NEXT
z2 = clock()
print "execution time : " & z2 - z1 & "ms"
z1 = clock()
'DIM i AS LONG
DIM cws AS CWSTR
FOR i = 1 TO 1000000
cws &= "Paul Squires"
NEXT
z2 = clock()
print "execution time : " & z2 - z1 & "ms"
print "Press any key..."
sleep
This means that it will be advisable to use CWSTR for general purpose and reserve CBSTR for COM.
The change has been just one line in the AppendBuffer procedure:
' IF (m_BufferLen + nNumBytes) > m_Capacity THEN this.ResizeBuffer( m_Capacity + m_GrowSize) --- old code ...
IF (m_BufferLen + nNumBytes) > m_Capacity THEN this.ResizeBuffer((m_BufferLen + nNumBytes) * 2)