[fpc-devel] Unicode support (yet again)

DaWorm daworm at gmail.com
Sat Sep 17 15:59:48 CEST 2011


This might be total crap, so bear with me a moment,  In an object like
a Stringlist, there is a default property such as Strings, such that
List.Strings[1] is equivalent to List[1], is there not?  If, as in
.NET or Java, all strings become objects, then you could have a String
object whose default property is Chars, whose type isn't really a
char, but another String whose length is one entity.  Thus code that
was written as MyString[1] would essentially behave the same as for
old shortstrings (ignoring for a moment the difference between ' and "
in specifying a literal char or string).  This string object could
have a property called Encoding that determined if it was UTF8 or
UTF16 or ANSI or raw bytes, and methods to trigger a direct
conversion, and AsXXX properties to convert for use in routines that
needed a different encoding, the need for which can be determined at
run time.

This may not be even feasible, and it will break some legacy code, but
I think those used to old style strings could get used to it very
quickly, and most of the details would be buried in the RTL where
people who didn't want to see them would not.  Of course, any code
using move or treating a section of shortstring as an open array would
still break, but perhaps that is a good thing.  We aren't running on
8088's any more so dangerous tricks in search of speed shouldn't be
needed as often, if at all.

Those who are looking for super efficiency won't find it here, but I
think months of discussions and thousands of messages pretty much
prove this is a complex task and only a complex solution will solve
it.  Even if the solution is nothing like the above, it is fairly
obvious that any attempt at a simple "one type fits all" solution
won't work, and if you are going to have to have multiple solutions,
to me it is better to bite the bullet and implement a full solution.

Jeff.



More information about the fpc-devel mailing list