[fpc-pascal] Generic String Functions

Michael Schnell mschnell at lumino.de
Fri Feb 28 15:15:52 CET 2014


On 02/28/2014 02:26 PM, Marco van de Voort wrote:
> I think it is better to start implementing it in a fork. A fork can 
> move much faster and make a reconnaissance of all problems and find 
> solutions for them, and see what you can do to improve compatibility. 
> One the fork has a functioning Lazarus again, you will have a much 
> better bargaining position than now while it is all paper, and some 
> people are strongly in favor, and the others say it won't work.

I see that trying different kinds of "Delphi compatibility plus 
OS-independence" (which obviously is a contradiction in itself) makes a 
lot of sense for the fpc / Lazarus combination.

But what do you mean by "fork" regarding the compiler and RTL (which 
would be the prerequisite for any decent LCL implementation).


A) Doing a "Generic" (fully dynamically encoded) String type.

Here, IMHO regarding the compiler a fork is not necessary, as this is a 
pure addition. If you don't like it, just don't create any string with 
that type. Defining the type of TStrings (and some other RTL introduced 
objects and functions would be a simple "ifdef" thingy. Of course the 
implementation of the functionality is mostly a pure addition, as well, 
as the actual type needs to be detected and handled appropriately (easy 
with TStringList, but potentially complex for stuff like TMemo, no idea 
(yet) with pos(), copy() and friends).


B) another idea of forking on behalf of Lazarus could be to do a "Delphi 
compatible" branch with a completely UTF16 based RTL (and compiler 
magic) and a "Lazarus compatible" branch with a completely UTF8 based 
RTL (and compiler magic)

-Michael



More information about the fpc-pascal mailing list