[fpc-devel] Russian locale information not compatible with FPC locale variables

Graeme Geldenhuys graemeg.lists at gmail.com
Tue Jul 29 11:21:22 CEST 2008


On Tue, Jul 29, 2008 at 10:45 AM, Daniƫl Mantione
<daniel.mantione at freepascal.org> wrote:
> The developers haven't talked about it yet, but I can imagine we will have
> some target platforms where sizeof(char)=1, which would provide for 100%
> compatibility with old code and some platforms where sizeof(char)=2, which
> will provide the unicode support for the future.

Sorry, but a unicode character can be anything from 1-4 bytes.  2
bytes will hardly cover the full unicode character range.

> For the time being you can prepare your own code by adding:
>
> type  char=widechar;
>      string=widestring;

I already use something similar to fpGUI...

  TfpgString      = type string;
  TfpgChar        = type string[4];


TfpgChar being 4 bytes to cover the whole Unicode range.

And some UTF-8 compliant string functions which are used often...

function  UTF8Copy(const s: string; StartCharIndex, CharCount: integer): string;
function  UTF8Length(const s: string): integer;
function  UTF8Pos(const SearchForText, SearchInText: string): integer;
procedure UTF8Delete(var S: string; Index, Size: integer);
procedure UTF8Insert(const Source: string; var S: string; Index: integer);

// short form (alias or convenience) functions for the UTF8 ones above
function  Copy8(const s: string; StartCharIndex, CharCount: integer): string;
function  Length8(const s: string): integer;
function  Pos8(const SearchForText, SearchInText: string): integer;
procedure Delete8(var S: string; Index, Size: integer);
procedure Insert8(const Source: string; var S: string; Index: integer);


And some UTF-8 file access functions....

// RTL wrapper filesystem functions with platform independant encoding
// These functions are common for all platforms and rely on
fpgXXXPlatformEncoding
function  fpgFindFirst(const Path: TfpgString; Attr: Longint; out
Rslt: TSearchRec): Longint;
function  fpgFindNext(var Rslt: TSearchRec): Longint;
function  fpgGetCurrentDir: TfpgString;
function  fpgSetCurrentDir(const NewDir: TfpgString): Boolean;
function  fpgExpandFileName(const FileName: TfpgString): TfpgString;
function  fpgFileExists(const FileName: TfpgString): Boolean;


And this is my point..... Many developers have such implementations in
there own code for some time now.  All these string encoding functions
should actually be in FPC (a long time ago).

> By the way, I do believe we need to be Delphi compatible here and thus know
> their implementation. Code exchange between Delphi & FPC otherwise becomes
> too hard for people.

A pipe dream, like I said before...  :-)    I don't see the point why
developers want to switch between compilers, using the same code base.
 Simply pick a compiler that can do it all, FPC!!  ;-)  That's what
our company did.  FPC fills our needs perfectly - cross platform, 32
bit and 64 bit support, an awesome FCL, loads of header translations
etc... We don't need Delphi!

Now the next item I would like to add to that awesome feature list of
FPC, is full Unicode support.


Regards,
 - Graeme -


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


More information about the fpc-devel mailing list