I don’t know what you know about .NET so I can’t know whether I know something you don’t know, cos I don’t know if you don’t know it or not. But if I did know that I knew something that you didn’t know, then self-evidently I must able to tell that, so being simultaneously in a state where-at I could not tell would create an internal paradox and I would consequently most likely disappear in a puff of logic.

But you only have to look at recent indications from CodeGear themselves that future Delphi.NET releases will not be so concerned with compatibility with Delphi.Win32 and will be more focused on leveraging the latest and greatest .NET technologies.

That in itself is very interesting, no?

Whatever else I may – or may not – know.

@Kashmi – I once had the same thought and created my own string builder-like class a while ago specifically to handle specialised cases that I thought could be optimised. e.g. building a delimited list from a known set of elements, where the resulting string size could be pre-calculated and pre-set and then the contents placed directly into the resulting string buffer.

Intuitively this should give some improvement in performance.

In reality I found that the expected performance gains were simply not realised, and performance was actually worse than building the string up using regular concatenation.

I didn’t analyse it too closely. I put it down to the fact that using a class to encapsulate this stuff necessarily introduces it’s own overhead (method calls vs – i.e. on top of – RTL code as well the construction and destruction of the class itself etc).

@Daniel (Luyo) – I haven’t compared EXE sizes and I think doing so is a little tricky as it isn’t possible to compare a Delphi 2009 ANSI executable with a Delphi 2009 Unicode one since of course the former is not possible to produce. We could only compare a 2009 exe with a pre-2009 exe and I think there are too many other factors involved between versions for such a comparison to provide any useful measure of the impact in this area of Unicode specifically.

@Kryvich – Thanks. I feel these results have a more “truthy” feel about them too.

@Bruce – Apparently you’re right about TStringBuilder. But I think this class can be significantly improved on the Win32 side, and it can be even more efficient than the String type in many cases.

A side question, is a Unicode exe bigger that a non Unicode one?, how much?

I don’t know, how far this affects Delphi and its memory manager, and could this be interpreted as preparations to introduction of garbage collection in Delphi.

1) Create builder instance
2) Set builder Capacity, either as the real predicted size of the future string or just as a big enough amount.
3) Now use convenient Add… methods
4) Get your result string.

Actually this way you’re preallocating memory, preventing its reallocations during additions. And this way you’re using nice methods instead of using SetLength(Result…) and manipulating with Result string or using a memory stream.

I wonder why Delphi 2009 still need its user(programmer) write below functions:

PosIEx()
PosBack()
FastReplace()

that support unicode?

I write them by myself. not satisfied, you know, speed is important!

Bear