Subject Re: [IBO] IBO - IB_String vs AnsiString
Author Carlos H. Cantu
I'm still not using D2009, but I remember to have read in several
blogs that, in terms of performance, changing String to Ansistring is
not good. Looks like the compiler has to do a lot of internal
conversions any time you use AnsiString parameters with functions and
procedures that are not specific designed for it.

So, my advice to Jason (and testers) is that you keep the eye open for
performance problems, specially in critical areas of the IBO code.
Maybe using a profiling tool can help to identify bottlenecks.

Basicly, what I mean is: changing Strings to Ansistring, at first, may
look like the easy and fastest way to make "old" code compatible with
D2009, but regarding performance, it may not be the best thing to do.
A search in may lead into several blog posts
regarding D2009 migration regarding strings details. Look, for

Carlos H. Cantu - -

mT> Hi,

mT> The ones who have the IBO 4.9 know that many String types where changed
mT> to AnsiString.

mT> While this is understandable, taking in account the amount of work
mT> required, this is unfortunate in certain areas like the ones who deal
mT> with the query parsing. I mean primarily code blocks (methods,
mT> procedures etc.) like Get/SetSQLWhere, SQLOrder etc. This means that
mT> when we use these code blocks we cannot use Unicode.

mT> But the problem here is that the _interface_ (iow the declaration) of
mT> these code blocks is changed. So we must change our variables to
mT> AnsiString in order to compile.

mT> There are some solutions here:

mT> 1. To use in _our_ code a string type like IB_String = AnsiString and
mT> when change it gradually to String when the library changes it's interface.

mT> 2. To use in _library's_ code the same approach as above. The 2nd has
mT> also the advance that we'll know where are the places in the library
mT> where 'AnsiString' must be changed back and where it must stay 'AnsiString'.

mT> Thoughts? Comments?

mT> m. Th.