| Subject: | I don't like TBytes... |
| Posted by: | Jason Smith (jas…@lrsupport.com.au) |
| Date: | Mon, 13 Oct 2008 |
Hi Guys,
Nick Hodges recently posted an article "Delphi in a Unicode World Part III:
Unicodifying Your Code". In that article, it mentioned about using TBytes as
a prefered way against using string as Data Buffers. While it sounds
technically correct or symantically a great idea, however, in practice, I
think using TBytes is a poor choice over the use of AnsiString.
The followings are my justifications:
(1) There is already TByteDynArray, why TBytes? It reminds me of the
complexity of .Net that you can do the same thing in hundreds of different
ways.
(2) While Delphi programmers are proud of "reference-countability" of
string, TBytes is Copy-On-Read, it hurts performance for memory intensive
manipulations (I'm aware that the internal checking of Copy-On-Write can
hurt performance on string manipulation as well. In this case, manipulating
data buffer via PAnsiChar pointing to AnsiString probably is the best way to
go for performance gain).
(3) Programmers would lose the abilities to manipulate Data Buffers in
convenient ways. e.g. Concat strings by just using + operator (althought
it's not encouraged for performance consideration), using StringReplace, Pos
and etc to deal with byte sequences.
(4) RawByteString is ok but conceptually it doesn't get approval from my
mind as a Delphi tradition of providing backward-compatibility.
(5) If someone thinks manually casting AnsiString to avoid compiler warnings
is tedious, I would argue adopting the TBytes way involves more works.
(6) I can see a lot of VCL source codes still using AnsiString as opposed to
using TBytes as Data Buffer. I think the success of Delphi lies on the
beauty of the traditions, doing things in simple and effective ways, as
opposed to some other programming languages, focusing on academically-sound
software enginnering but low usability (StringBuilder?)
I'm happy to be pointed out if any part of my comments doesn't make sense.
Regards,
Jason