[fpc-devel] Unicodestring branch, please test and help fixing

[Graeme Geldenhuys]

On Wed, Sep 10, 2008 at 7:15 AM, listmember <listmember at letterboxes.org> wrote:
> 1) since each character is a class, memory requirements are increased
> several fold.
>
> 2) Again, the charater-as-class also means that the speed with wich we can
> create and destroy (and manipulate) a string is a lot slower.

I'm not saying that FPC needs to do any of this, I am simply
commenting with my experience in OOP. Both the above issues could be
addressed (or minimised) by using the Flyweight and Proxy design
patterns. See the GOF (Gang of Four) book where they create an rich
text editor. In your example, a TCharacter instance could be shared
between other 'of the same" character in a single string (TString), or
maybe the even have a global pool of TCharacters shared between many
strings. When nobody (TString's) is referencing a TCharacter instance
in the pool, it can be free'd. Just like reference counted objects.

I don't know the internals of FPC, so I can't say if this is more or
less work than the current implementations.  But it does allow
TCharacter and TString to be more intelligent with what encoding it
represents etc... And if you have an application with many strings, it
might actually save memory, because flyweight objects are used from a
pool.

Regards,
 - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/