Re: [fpc-devel] Unicode resource strings
Am 20.08.2012 06:52, schrieb Martin Schreiber: On Sunday 19 August 2012 09:41:48 Paul Ishenin wrote: 19.08.12, 15:18, Martin Schreiber wrote: Hi, In 2008 and 2011 there were threads about FPC and Unicode resource strings with the conclusion that FPC does not support them. Are Unicode resource strings implemented in FPC now? I did not find it in documentation. At the moment FPC resource strings are still ansi strings even in delphi unicode mode. Thanks Jonas and Paul. Please permit a little comment. All what was missing for good multi language Unicode support in FPC after Florian and Peter implemented widestrings (which were reference counted on all platforms at the beginning!) are Unicode resource strings. Now, many years later, we still don't have Unicode resource strings but we have codepage aware 8-bit strings? I don't understand the priorities. Just to avoid confusion: The reference counted 2-byte string type on all platforms is UnicodeString, not WideString (the latter is not reference counted on Windows platforms). The codepage aware string type was added to 2.7.1, because there already existed a branch for this and just needed to be merged. There does not yet exist any code for Unicode resource strings. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] 64 bit integer result in Win32 problem
ABorka wrote on Mon, 20 Aug 2012: Win32 .exe compiled on Win64 computer, latest SVN build. I am trying to multiply 2 Integers (Declared as LongInt but sometimes need to use it as LongWord) and put the result into a QWord (64bit unsigned) result variable on Win32. However, it seems that the result is always cut to 32bit. In Pascal, the type of the result of an expression only depends on its arguments, never on what you do with it afterwards. Additionally, integer expressions are evaluated using the native bit width if all factors are = 32 bit, which is 32 bit on 32 bit systems (exception: operations involving both longint and cardinal). If you want a 64 bit result, typecast one of the factors of the expressions to 64 bit. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Monday 20 August 2012 09:52:47 Sven Barth wrote: Just to avoid confusion: The reference counted 2-byte string type on all platforms is UnicodeString, not WideString (the latter is not reference counted on Windows platforms). WideString was reference counted on Windows when it was introduced in FPC. The FPC revision was 1.9.x IIRC. The first bug report I made in wide area is from 30.4.2004 and revision 1.9.3. http://bugs.freepascal.org/view.php?id=5084 Later it has been changed to OLE string on Windows because of Delphi compatibility. http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg07520.html http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg03010.html http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg03018.html Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On 20/08/12 08:52, Sven Barth wrote: Just to avoid confusion: The reference counted 2-byte string type on all platforms is UnicodeString, not WideString (the latter is not reference counted on Windows platforms). Please correct me if I am wrong, but I think WideString was reference counted an all platforms in the beginning - like Martin mentioned. Later it was changed, and the new UnicodeString become the reference counted on all platforms type. The codepage aware string type was added to 2.7.1, because there already existed a branch for this and just needed to be merged. There does not yet exist any code for Unicode resource strings. FPC's Unicode support is still in its infancy. It is not just resource strings that are missing. As my recent message from the fpc-users mailing list shows. Vital decisions of how Unicode should be implemented are still not decided by the FPC team. There is a major problem in the FPC project though. The FPC team seems to be dead-locked on how to implement Unicode features. Nobody can agree on anything. Thus no work can be started on the RTL and FCL. In the meant time many projects keep implementing there own Unicode workarounds. Not a good sign, but all we can do. So the BIG question remains: When will the FPC team sit down and hash out the details of implementing Unicode support? Please note, I'm not saying implement it, just saying... agree on how it should be implemented. If the FPC team stays in a dead-lock, then maybe the better option would be to allow the public to vote on it. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Mon, 20 Aug 2012 06:52:23 +0200 Martin Schreiber mse00...@gmail.com wrote: On Sunday 19 August 2012 09:41:48 Paul Ishenin wrote: 19.08.12, 15:18, Martin Schreiber wrote: Hi, In 2008 and 2011 there were threads about FPC and Unicode resource strings with the conclusion that FPC does not support them. Are Unicode resource strings implemented in FPC now? I did not find it in documentation. At the moment FPC resource strings are still ansi strings even in delphi unicode mode. Thanks Jonas and Paul. Please permit a little comment. All what was missing for good multi language Unicode support in FPC after Florian and Peter implemented widestrings (which were reference counted on all platforms at the beginning!) are Unicode resource strings. I guess most people would say that good multi language Unicode support in FPC requires a Unicode supporting RTL. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On 08/20/2012 10:26 AM, Graeme Geldenhuys wrote: Nobody can agree on anything. Which is rather understandable (as several a long winding discussion in this forum showed). FPC is always eager to provide as full Delphi compatibility as possible, and the Delphi Unicode support is not very nice. Decent Unicode is an extremely complex issue, anyway (trying to provide as well user friendly usage, and and versatility, and good backwards compatibility, and good portability, and good performance). If necessary compatibility to the seemingly abysmal current Delphi and the necessity to reuse the code of the existing (seemingly rather good) implementation comes into play, a common denominator seems to be very hard to find. If the FPC team stays in a dead-lock, then maybe the better option would be to allow the public to vote on it. When thinking about Lazarus now exiting the v0.xxx state not a good omen. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Monday 20 August 2012 10:35:09 Mattias Gaertner wrote: Thanks Jonas and Paul. Please permit a little comment. All what was missing for good multi language Unicode support in FPC after Florian and Peter implemented widestrings (which were reference counted on all platforms at the beginning!) are Unicode resource strings. I guess most people would say that good multi language Unicode support in FPC requires a Unicode supporting RTL. Not necessarily. Lazarus, fpGUI and MSEgui have their own implementations which don't need to be strictly Delphi compatible and therefore can better suit the users needs. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
In our previous episode, Martin Schreiber said: Not necessarily. Lazarus, fpGUI and MSEgui have their own implementations which don't need to be strictly Delphi compatible and therefore can better suit the users needs. IMHO it is more a question if a hard break like Delphi is necessary or that there is a way to switch basetypes. (like what to do with overrides?) I'm starting to believe the hard break is the only serious option. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Monday 20 August 2012 11:10:27 Marco van de Voort wrote: In our previous episode, Martin Schreiber said: Not necessarily. Lazarus, fpGUI and MSEgui have their own implementations which don't need to be strictly Delphi compatible and therefore can better suit the users needs. IMHO it is more a question if a hard break like Delphi is necessary or that there is a way to switch basetypes. (like what to do with overrides?) I'm starting to believe the hard break is the only serious option. My opinion: Do what you want with RTL and FCL but optimize the compiler so it is possible to build optimal frameworks for different requirements. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Graeme Geldenhuys wrote: On 20/08/12 08:52, Sven Barth wrote: Just to avoid confusion: The reference counted 2-byte string type on all platforms is UnicodeString, not WideString (the latter is not reference counted on Windows platforms). Please correct me if I am wrong, but I think WideString was reference counted an all platforms in the beginning - like Martin mentioned. Later it was changed, and the new UnicodeString become the reference counted on all platforms type. So could somebody make a definitive statement: for basic two-byte Unicode handling, what types should be used? I've got a couple of terminal emulators using WideChar and WideString for internal manipulation, what /should/ I be using? and where does it leave things like Sorokin's regex unit, which similarly use WideChar and WideString? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Mark Morgan Lloyd wrote on Mon, 20 Aug 2012: So could somebody make a definitive statement: for basic two-byte Unicode handling, what types should be used? unicodestring, because it is generally somewhat faster than widestring on Windows. On non-Windows platforms, widestring=unicodestring in any case. I've got a couple of terminal emulators using WideChar and WideString for internal manipulation, what /should/ I be using? and where does it leave things like Sorokin's regex unit, which similarly use WideChar and WideString? widechar = unicodechar on all platforms. On Windows, where widestring is not the same as unicodestring, one can be converted to the other without any dataloss. Again, you may get some minor speed penalty on Windows, but it's unlikely you'll notice it. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Mon, 20 Aug 2012 10:56:32 +0200 Martin Schreiber mse00...@gmail.com wrote: On Monday 20 August 2012 10:35:09 Mattias Gaertner wrote: Thanks Jonas and Paul. Please permit a little comment. All what was missing for good multi language Unicode support in FPC after Florian and Peter implemented widestrings (which were reference counted on all platforms at the beginning!) are Unicode resource strings. I guess most people would say that good multi language Unicode support in FPC requires a Unicode supporting RTL. Not necessarily. Lazarus, fpGUI and MSEgui have their own implementations which don't need to be strictly Delphi compatible and therefore can better suit the users needs. Yes, specializations have advantages. I only think that good Unicode support in FPC sounds as if all the important things of Unicode are in FPC and you don't need extra libs. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Am 20.08.2012 10:26, schrieb Martin Schreiber: On Monday 20 August 2012 09:52:47 Sven Barth wrote: Just to avoid confusion: The reference counted 2-byte string type on all platforms is UnicodeString, not WideString (the latter is not reference counted on Windows platforms). WideString was reference counted on Windows when it was introduced in FPC. The FPC revision was 1.9.x IIRC. The first bug report I made in wide area is from 30.4.2004 and revision 1.9.3. http://bugs.freepascal.org/view.php?id=5084 Later it has been changed to OLE string on Windows because of Delphi compatibility. http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg07520.html http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg03010.html http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg03018.html Now I understand what you ment with which were reference counted on all platforms at the beginning! ;) [I came to FPC during the 2.2 series] Thank you for clarification. Nevertheless to avoid confusion one should pay attention to which string type one mentions. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Monday 20 August 2012 11:39:34 Mattias Gaertner wrote: Not necessarily. Lazarus, fpGUI and MSEgui have their own implementations which don't need to be strictly Delphi compatible and therefore can better suit the users needs. Yes, specializations have advantages. I only think that good Unicode support in FPC sounds as if all the important things of Unicode are in FPC and you don't need extra libs. True. I actually meant the possibilities of the compiler. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Jonas Maebe wrote: Mark Morgan Lloyd wrote on Mon, 20 Aug 2012: So could somebody make a definitive statement: for basic two-byte Unicode handling, what types should be used? unicodestring, because it is generally somewhat faster than widestring on Windows. On non-Windows platforms, widestring=unicodestring in any case. I've got a couple of terminal emulators using WideChar and WideString for internal manipulation, what /should/ I be using? and where does it leave things like Sorokin's regex unit, which similarly use WideChar and WideString? widechar = unicodechar on all platforms. On Windows, where widestring is not the same as unicodestring, one can be converted to the other without any dataloss. Again, you may get some minor speed penalty on Windows, but it's unlikely you'll notice it. Thanks Jonas, noted. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On 08/20/2012 11:30 AM, Mark Morgan Lloyd wrote: for basic two-byte Unicode handling, what types should be used? :-) *That* is part of the problem :-) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On 08/20/2012 10:46 AM, Michael Schnell wrote: long winding discussion in this forum .. and on the Lazarus forum ... -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On 20/08/12 10:22, Martin Schreiber wrote: On Monday 20 August 2012 11:10:27 Marco van de Voort wrote: I'm starting to believe the hard break is the only serious option. My opinion: Do what you want with RTL and FCL but optimize the compiler so it is possible to build optimal frameworks for different requirements. +1 Get the compiler to decently support Unicode. At least the public can then build on that however they want. The FPC RTL can then later be mangled to be a delphi clone - or leave it to other projects to implement there own RTL's. At the moment the Delphi-compatibility arguments is holding FPC back in the stone ages. All the advantages of FPC is starting to fall away. Delphi hasn't done anything major in years (Embarcadero simply buy out other projects and launch it as their own in the next Delphi version - which is a disaster too). And with all this delphi compatibility arguments, the FPC project wants to be one step behind that. Crazy! Like Martin with MSEgui, I would rather push fpGUI tiOPF forward by implementing my own unicode rtl or required functions/classes if I must. The delphi compatibility is purely a myth too. FPC isn't compatible with a single Delphi version (except maybe the 10 year old Delphi 7). For any newer Delphi versions, it has bits of this, bits of that... I wouldn't call that compatible. So lets try and keep the delphi compatibly out of this discussion of the FPC Compiler and Unicode support. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
In our previous episode, Graeme Geldenhuys said: The delphi compatibility is purely a myth too. FPC isn't compatible with a single Delphi version (except maybe the 10 year old Delphi 7). For any newer Delphi versions, it has bits of this, bits of that... I wouldn't call that compatible. That is an opinion of you and maybe Martin (S), and just that. I don't agree, and frankly I think it is ridiculous. Compatibility is what brought the projects so far (and fact is that you yourself were asking about compatibility only a few days ago) Not to least because all the anti-Delphians can't seem to agree on anything but their common anti-Delphi drum. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On 19.08.2012 10:18, Martin Schreiber wrote:
Hi,
In 2008 and 2011 there were threads about FPC and Unicode resource strings
with the conclusion that FPC does not support them.
Are Unicode resource strings implemented in FPC now? I did not find it in
documentation.
Is there a replacement or supplement for
http://wiki.freepascal.org/FPC_Unicode_support
which answers such questions?
Thanks, Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Dear FPC-all!
Since the beginning of my FPC use I maintain the following FPC/Delphi
compatible code.
to get unicode string from resource i use
function _W(const pRec: PResStringRec):WideString;
begin
try
Result:=LoadResStringW(pRec);
except
Result:='';
end;
end;
example of use
// this may be placed in separate includes for Delphi and FPC
{$ifdef FPC}
resourcsestring
sSomeConstant='This is UTF-8 encoded resource string';
{$else}
resourcsestring
sSomeConstant='This is win encoded resource string';
{$endif}
var ws:WideString;
ws:=_W(@sSomeConstant); // this is X-platform way and Delphi/FPC compatible
// FPC version of string loader
function LoadResStringW(const pRec: PResStringRec): WideString;inline;
begin
if pRec=nil then
Result:=''
else
begin
Result:=UTF8Decode(PAnsiString(pRec)^);
end;
end;
// Delphi version uses WinAPI call
function LoadResStringW(const pRec: PResStringRec): WideString;
var
hInst:cardinal;
Buffer: array [0..1023] of char;
begin^M
if pRec = nil then Exit;
if pRec^.Identifier 64*1024 then
begin
hInst:=FindResourceHInstance(pRec^.Module^);
// try wide
if LoadStringW(hInst,pRec^.Identifier, @Buffer, SizeOf(Buffer))0 then
Result:=PWideChar(@Buffer)
else // try narrow
if LoadString(hInst,pRec^.Identifier, @Buffer, SizeOf(Buffer))0 then
Result:=PChar(@Buffer)
else
Result:='-lost-';
end
else
Result := PWideChar(pRec^.Identifier);
end;
regards
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Graeme Geldenhuys wrote on Mon, 20 Aug 2012: Get the compiler to decently support Unicode. At least the public can then build on that however they want. The FPC RTL can then later be mangled to be a delphi clone - or leave it to other projects to implement there own RTL's. At the moment the Delphi-compatibility arguments is holding FPC back in the stone ages. Stop with the drama already, seriously. The Delphi-compatibility arguments are not about the compiler, but about the RTL/FCL. The compiler already fully supports unicode, except for resourcestrings. That has nothing to do with Delphi compatibility or not, but is simply a matter of nobody caring enough to implement it. The bug report requesting such support already dates from 2005: http://bugs.freepascal.org/view.php?id=6477 Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Monday 20 August 2012 12:37:24 Anton Kavalenka wrote: Since the beginning of my FPC use I maintain the following FPC/Delphi compatible code. Does it work if the source has been compiled with -Fcutf8 on Windows? IIRC FPC converts the source utf8 constants to the system encoding before building the resource string tables. Another question is the encoding of the *.rst files we need in the MSEi18n tool. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On 20 August 2012 11:36, Marco van de Voort mar...@stack.nl wrote: I don't agree, and frankly I think it is ridiculous. Compatibility is what brought the projects so far (and fact is that you yourself were asking about compatibility only a few days ago) Yes, I gave FPC 2.7.1 the benefit of the doubt... And what did my little experiment prove? That FPC is not nearly compatible enough with even a D2009 project - that's a Delphi version that is 4 years old, and within a month superseded by yet another new Delphi version. Year-on-Year the delphi compatibility is getting more and more outdated. So stop drumming about the delphi compatibility when it doesn't exist, other to a 10 year old obsolete Delphi version. And even with your delphi compatibility drumming, nobody is moving to FPC from Delphi any more, now that Delphi is again seeing some development work being done by its latest owner. Yes and that even includes you. Anyway, I would have loved to take this for a few more rounds in fpc-other, but I'm a bit busy at the moment. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On 20.08.2012 14:03, Martin Schreiber wrote:
On Monday 20 August 2012 12:37:24 Anton Kavalenka wrote:
Since the beginning of my FPC use I maintain the following FPC/Delphi
compatible code.
Does it work if the source has been compiled with -Fcutf8 on Windows? IIRC FPC
converts the source utf8 constants to the system encoding before building the
resource string tables. Another question is the encoding of the *.rst files
we need in the MSEi18n tool.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
I use separate include files for resource strings in UTF-8 and in win1251.
{$ifdef FPC}
{$i resources-utf8.inc}
{$else}
{$i resources-cp1251.inc}
{$endif}
IIRC FPC does NOT convert resource strings into system encoding.
Besides my applications use FPC runtime to extract own resorcestrings
into external files (for translation).
procedure ExtractStringResources;
var
os:TFileStream;
begin
if not FileExists(DefLocalesPath) then CreateDir(DefLocalesPath);
os:=TFileStream.Create(DefLocalesPath+PathDelim+ExtractFileName(ParamStr(0))+'.fpcres',fmCreate);
try
SetResourceStrings(@DoSaveStringResource,os);
finally
os.Free;
end;
end;
function
DoSaveStringResource(Name,Value:AnsiString;Hash:Longint;arg:pointer):AnsiString;
var
os:TStream absolute arg;
begin
Result:='';
os.WriteBuffer(Hash,sizeof(Hash));
os.WriteAnsiString(Value);
end;
Resources from both Windows and Linux EXE are extracted in UTF-8 (not
win1251).
Anton
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Monday 20 August 2012 14:32:22 Anton Kavalenka wrote:
Resources from both Windows and Linux EXE are extracted in UTF-8 (not
win1251).
Do you compile with -Fcutf8 or {$codepage utf8}?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On 20.08.2012 15:45, Martin Schreiber wrote:
On Monday 20 August 2012 14:32:22 Anton Kavalenka wrote:
Resources from both Windows and Linux EXE are extracted in UTF-8 (not
win1251).
Do you compile with -Fcutf8 or {$codepage utf8}?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
I use default implicit settings (I suppose it is UTF8).
None of my sources contain codepage controlling directive.
Anton
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Monday 20 August 2012 14:45:34 Anton Kavalenka wrote:
On 20.08.2012 15:45, Martin Schreiber wrote:
On Monday 20 August 2012 14:32:22 Anton Kavalenka wrote:
Resources from both Windows and Linux EXE are extracted in UTF-8 (not
win1251).
Do you compile with -Fcutf8 or {$codepage utf8}?
I use default implicit settings (I suppose it is UTF8).
None of my sources contain codepage controlling directive.
This probably explains the difference. MSEgui uses UnicodeString and is
compiled with -Fcutf8 for assignement of Unicode string constants to
UnicodeString variables and transparent conversion of Unicode string
constants to system encoding at runtime.
Without -Fcutf8 or {$codepage utf8} FPC copies the 8 bit strings as is into
the executable.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
In our previous episode, Graeme Geldenhuys said: Yes, I gave FPC 2.7.1 the benefit of the doubt... And what did my little experiment prove? That FPC is not nearly compatible enough with even a D2009 project - that's a Delphi version that is 4 years old, and within a month superseded by yet another new Delphi version. Year-on-Year the delphi compatibility is getting more and more outdated. So stop drumming about the delphi compatibility when it doesn't exist, other to a 10 year old obsolete Delphi version. A nice example of Creative measuring. FPC 2.6.0 of last januari has mostly 2006-2007 features. And D2009 is a landmark, version, the first one to major break compatibility in a decade with many very major features. (unicode is just one of them), so it is logical that will take more than a year. (2.6.0 branched off just over an year ago) And even with your delphi compatibility drumming, nobody is moving to FPC from Delphi any more, now that Delphi is again seeing some development work being done by its latest owner I have no idea where you base this on. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Am 20.08.2012 10:26, schrieb Graeme Geldenhuys: So the BIG question remains: When will the FPC team sit down and hash out the details of implementing Unicode support? Please note, I'm not saying implement it, just saying... agree on how it should be implemented. Fine with me: let's kick all those complicated utf-8 and utf-16 encodings and just use utf-32 for the unicodestring type, it's very simple to use, no platform is prefered over others, normal PCs have 8 GB+ today so memory is not an issue anymore neither is CPU power. Clean, simple, easy. If the FPC team stays in a dead-lock, then maybe the better option would be to allow the public to vote on it. And who implements it? The public votes as well? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Fine with me: let's kick all those complicated utf-8 and utf-16 = Isn't UCS-2 enough for all possible coverage on the Earth planet ? Even chineese people use 64K- dictionary (the sipmplified alphabet) for computer typing. PS: UCS-4 (and UTF-8 BTW) looks appropriate for future contacts with aliens with their unknown alphabets, though :) Is to be ready for contacts with them the purpose ? Then UCS-2 with surrogate pairs is a solution as well doesn't impose double memory allocation. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On 20 August 2012 15:11, Florian Klämpfl flor...@freepascal.org wrote: And who implements it? The public votes as well? Why are you complaining? You have your hobby projects (FPC etc.), and I have mine (fpGUI, tiOPF, OnGuard, MPP etc). I have no problem contributing to something I actually know or (have the time to) understand. In the case of FPC that would translated to the RTL, fpdoc, various FCL packages. But then many disagree with my past suggestions for RTL changes - so howe successful my attempts will be, I don't know. Anyway, I'll rather leave the Compiler internals in the more capable hands like you (just in case you didn't know, that was a compliment). -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On 20 August 2012 15:24, Ivanko B ivankob4m...@gmail.com wrote: Isn't UCS-2 enough for all possible coverage on the Earth planet ? No, Unicode is large than UCS-2. Also about your alien language comment. Unicode includes code points not just for spoken languages, but for anything that can be written. eg: musical notes, scientific symbols, advanced math symbols, map glyphs, smiley faces (can be used in in email's, IM programs etc without embedded images), braille etc -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
This probably explains the difference. MSEgui uses UnicodeString and is compiled with -Fcutf8 for assignement of Unicode string constants to UnicodeString variables and transparent conversion of Unicode string constants to system encoding at runtime. = Really. MSEgui doesn't expose any problems with unicode - neither in runtime not for string constants from source files. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
No, Unicode is large than UCS-2. Also about your alien language comment. Unicode includes code points not just for spoken languages, but for anything that can be written. eg: musical notes, scientific symbols, advanced math symbols, map glyphs, smiley faces (can be used in in email's, IM programs etc without embedded images), braille etc They all have already been present in UCS-2, AFAIK. Do You means possible extensions in the future ? Are they really possible ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Am 20.08.2012 16:25, schrieb Graeme Geldenhuys: On 20 August 2012 15:11, Florian Klämpfl flor...@freepascal.org wrote: And who implements it? The public votes as well? Why are you complaining? You have your hobby projects (FPC etc.), and I have mine (fpGUI, tiOPF, OnGuard, MPP etc). I have no problem contributing to something I actually know or (have the time to) understand. In the case of FPC that would translated to the RTL, fpdoc, various FCL packages. But then many disagree with my past suggestions for RTL changes - This is exactly the problem: everybody has its own opinion. so howe successful my attempts will be, I don't know. Anyway, I'll rather leave the Compiler internals in the more capable hands like you (just in case you didn't know, that was a compliment). Besides the resourcestrings I'am not aware of any unicodestring issues in the *compiler*. If there are, please report them to the issue tracker. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Hi,
On 20 August 2012 15:43, Florian Klämpfl flor...@freepascal.org wrote:
Besides the resourcestrings I'am not aware of any unicodestring issues
in the *compiler*. If there are, please report them to the issue tracker.
I have heard various back-and-forth comments about UnicodeString and
others, which makes me believe the compiler+unicode is still
incomplete, or at least not set in stone (understood as: don't really
use, because it could still change).
For example:
* new mode 'delphiunicode' was introduced, but what about developers
wanting Unicode,
but the project is a pure FPC project (it has no history of Delphi)?
* Only in 'delphiunicode' mode is String = UnicodeString (I guess
the same issue as above)
* All other modes String = AnsiString or ShortString based on {$H+}
or not. String is the most
used type, and so too is the objfpc mode. So shouldn't String =
UnicodeString in FPC 2.8.0 release
for mode objfpc too?
* UnicodeString is always UTF-16 (so everything but Windows takes a
conversion penalty)!
As far as I remember, that was good feedback from developers like
the idea of having
UnicodeString as UTF-16 on windows and under Linux, MacOSX, Unix
etc it is UTF-8.
* The above point would also alleviate the codepage compiler warning
under Linux/Unix/MacOS when
delphiunicode mode (the only mode where String = UnicodeString).
Then again ALL text files I have
even seen use UTF-8 as encoding, so even under Windows, source
code should be assumed UTF-8
encoded. Java, C#, W3C (HTML XML) etc all do that too.
* Unicode resource strings as Martin mentioned is not working yet.
There are lot of uncertanties, thus developers are reluctant to start
using (and testing it), because they might end up having to change
100's of thousands of lines of code later again.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Unicode in the RTL (my ideas)
...Continuing the discussion of a Unicode rTL in a new thread as promised...
I obviously have lot of issues with the RTL suggestions being thrown
around in the past. eg: I have heard lots about the RTL mostly likely
being UTF-16 only, or being spilt into 3 versions AnsiString, UTF-16
and UTF-8 (a maintenance nightmare). Why? Why can't you have code as
follows:
{$IFDEF WINDOWS}
UnicodeString = type AnsiString(CP_UTF16);
{$ELSE}
// probably not strictly correct, but assuming *nix here. But
you get the idea
UnicodeString = type AnsiString(CP_UTF8);
{$ENDIF
String = type UnicodeString;
Char = type String[4]; // the maximum size of a Unicode codepoint
is 4 bytes
Now the RTL can have something like
Exception = class
public
property Message: string read
end;
TStings = class(...)
public
function Add(const AText: String); integer;
// I'm not 100% about the actual signature, but UTF-8 is
probably a very safe bet
// for the default, because 99.% of unicode text is stored
in UTF-8, and
// ANSI text could safely load too. If the developers knows
otherwise, they can always
// pass a different encoding constant to the function.
procedure LoadFromFile(const AFilename: String; AEncoding:
TEncoding = cp_UTF8);
end;
This should be pretty delphi compatible, meaning Delphi code could
probably compile under FPC Windows without much need for change. As
far as I know delphi compatibility is only meant for the Windows
platform, and Delphi code moving to FPC (not the other way round).
Also, now the locale variables can have things like the Russian
Thousand Separator (U+00A0) character stored in a Char too. For those
that didn't know, the Russian locale uses the non-breaking space as a
thousand separator, which in UTF-8 is 'C2 A0' (bytes) and takes up 2
bytes of memory. There might be other similar locale variables in
other languages that might take up more bytes per.
In general encoding conversions will be reduced on each platform, or
no conversion is needed at all, because the native encoding is always
used.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Am 20.08.2012 18:05, schrieb Graeme Geldenhuys:
Hi,
On 20 August 2012 15:43, Florian Klämpfl flor...@freepascal.org wrote:
Besides the resourcestrings I'am not aware of any unicodestring issues
in the *compiler*. If there are, please report them to the issue tracker.
I have heard various back-and-forth comments about UnicodeString and
others, which makes me believe the compiler+unicode is still
incomplete, or at least not set in stone (understood as: don't really
use, because it could still change).
True, it's not yet released but in 2.7.1 aka trunk for development,
testing and bug fixing.
For example:
* new mode 'delphiunicode' was introduced, but what about developers
wanting Unicode,
but the project is a pure FPC project (it has no history of Delphi)?
Then use {$mode objfpc} {$modeswitch unicodestrings}
{$mode delphiunicode} is for people who try to compile delphi code with
least as possible effort.
* Only in 'delphiunicode' mode is String = UnicodeString (I guess
the same issue as above)
See above.
* All other modes String = AnsiString or ShortString based on {$H+}
or not. String is the most
used type, and so too is the objfpc mode. So shouldn't String =
UnicodeString in FPC 2.8.0 release
for mode objfpc too?
No, it breaks old code for nothing. We can add an objfpcunicode mode or
whatever you like.
* UnicodeString is always UTF-16 (so everything but Windows takes a
conversion penalty)!
A decision has been made and you are not happy with it. Fine. But before
you called the fpc team being in a deadlock? Overcoming such deadlocks
does not make everybody happy.
As far as I remember, that was good feedback from developers like
the idea of having
UnicodeString as UTF-16 on windows and under Linux, MacOSX, Unix
etc it is UTF-8.
* The above point would also alleviate the codepage compiler warning
under Linux/Unix/MacOS when
delphiunicode mode (the only mode where String = UnicodeString).
Then again ALL text files I have
even seen use UTF-8 as encoding, so even under Windows, source
code should be assumed UTF-8
encoded. Java, C#, W3C (HTML XML) etc all do that too.
* Unicode resource strings as Martin mentioned is not working yet.
Indeed, this can be fixed.
There are lot of uncertanties, thus developers are reluctant to start
using (and testing it), because they might end up having to change
100's of thousands of lines of code later again.
Yes, this certanty is only given when we are at 2.8.0
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Mattias Gaertner schrieb: I guess most people would say that good multi language Unicode support in FPC requires a Unicode supporting RTL. Please clarify: *Unicode* or UTF-16 support? Unicode is covered by both UTF-8 and UTF-16, so it's not really important which encoding is used in the supporting procedures. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Mark Morgan Lloyd schrieb: I've got a couple of terminal emulators using WideChar and WideString for internal manipulation, what /should/ I be using? and where does it leave things like Sorokin's regex unit, which similarly use WideChar and WideString? Depends on which libraries you use. AFAIK SBCS RegEx works for both Ansi and UTF-8 strings, so that an UTF-16 library is optional. For the terminal emulators I'd think that it's sufficient to introduce an internal string type that allows to switch between UTF-8 and UTF-16, so that the (different?) behaviour can be tested. When there exist differences, this indicates that the WideString emulators *only* handle Unicode BMP characters, not surrogate pairs, and you have to decide whether this restriction is okay for you. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Graeme Geldenhuys schrieb: The delphi compatibility is purely a myth too. FPC isn't compatible with a single Delphi version (except maybe the 10 year old Delphi 7). For any newer Delphi versions, it has bits of this, bits of that... I wouldn't call that compatible. +1 Since the Delphi versions are incompatible amongst each other, how can a single RTL and compiler mode switch support *all* these versions? The same argument for the LCL, which is (and can not be) compatible with any specific VCL version, on non-Win32 platforms/widgetsets. So lets try and keep the delphi compatibly out of this discussion of the FPC Compiler and Unicode support. +1 DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Graeme Geldenhuys schrieb: On 20/08/12 08:52, Sven Barth wrote: Just to avoid confusion: The reference counted 2-byte string type on all platforms is UnicodeString, not WideString (the latter is not reference counted on Windows platforms). Please correct me if I am wrong, but I think WideString was reference counted an all platforms in the beginning - like Martin mentioned. Later it was changed, and the new UnicodeString become the reference counted on all platforms type. WideStrings on Windows platforms are allocated in *system* space, so that they can be used across processes. Reference counting can occur only according to the Windows (COM) rules. Delphi UnicodeStrings are stored in the (local) program space instead, so that local reference counting can be used. Dunno about passing such strings to other processes, though. The codepage aware string type was added to 2.7.1, because there already existed a branch for this and just needed to be merged. There does not yet exist any code for Unicode resource strings. FPC's Unicode support is still in its infancy. It is not just resource strings that are missing. As my recent message from the fpc-users mailing list shows. Vital decisions of how Unicode should be implemented are still not decided by the FPC team. There is a major problem in the FPC project though. The FPC team seems to be dead-locked on how to implement Unicode features. Nobody can agree on anything. Thus no work can be started on the RTL and FCL. In the meant time many projects keep implementing there own Unicode workarounds. Not a good sign, but all we can do. IMO UTF-8 is supported by all platforms, so that there exists no urgent need for adding UTF-16 support. More problematic is the default String type break between older (AnsiString) and newer (UnicodeString) Delphi versions. The consequence of following *that* decision were incompatible FCL (and LCL) classes, resulting in double maintenance efforts. This duplication can be avoided by using the implicit string conversions, offered by the new string types. This applies also to the handling of resource strings. The runtime impact depends on the string model used in a *program*, where the use of UTF-16 strings would require many conversions in *interfacing* UTF-8 components/libraries. It's unclear whether UTF-16 strings really allow for faster string handling, since *full* Unicode support still has to take into account UTF-16 *surrogate pairs*, no real difference vs. handling of UTF-8 multibyte sequences. So the BIG question remains: When will the FPC team sit down and hash out the details of implementing Unicode support? Please note, I'm not saying implement it, just saying... agree on how it should be implemented. If the FPC team stays in a dead-lock, then maybe the better option would be to allow the public to vote on it. What special support do you expect? Which of these features are essentially different for UTF-8 and UTF-16? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Hi,
On 20 August 2012 17:37, Florian Klämpfl flor...@freepascal.org wrote:
True, it's not yet released but in 2.7.1 aka trunk for development,
testing and bug fixing.
Understood. I'm normally reluctant to try FPC Trunk, but thought that
I better try this time round.
* new mode 'delphiunicode' was introduced, but what about developers
wanting Unicode,
but the project is a pure FPC project (it has no history of Delphi)?
Then use {$mode objfpc} {$modeswitch unicodestrings}
Ah, I guess I didn't fully understand the modeswitch option. I'll
experiment with this a bit more.
used type, and so too is the objfpc mode. So shouldn't String =
UnicodeString in FPC 2.8.0 release for mode objfpc too?
No, it breaks old code for nothing. We can add an objfpcunicode mode or
whatever you like.
Now that I know a bit more about the modeswitch option, I could simply
modify my unit templates, so a new compiler mode is probably not
needed then.
* UnicodeString is always UTF-16 (so everything but Windows takes a
conversion penalty)!
A decision has been made and you are not happy with it. Fine. But before
you called the fpc team being in a deadlock?
Many things by the FPC team get discussed or debated behind closed
doors, so how are we even in the fpc-devel mailing list to know what
is decided. Last I read in fpc-devel it was still heavily debated and
no decision was in sight. I guess now we know, the decision is UTF-16
everywhere where UnicodeString is used.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On 20 August 2012 18:42, Hans-Peter Diettrich drdiettri...@aol.com wrote: *only* handle Unicode BMP characters, not surrogate pairs, and you have to decide whether this restriction is okay for you. Such a restriction should NEVER be okay! Otherwise Unicode support is incomplete. That is what makes UTF-8 so great. It's perfect for (byte) streaming, no little- or big-endian to worry about, already the correct encoding for HTML, XML and in fact 99.99% of all text files, and NO SURROGATE PAIRS. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Since the Delphi versions are incompatible amongst each other, how can a single RTL and compiler mode switch support *all* these versions? Really the team seems to fights to FPC + Lazarus be capable of building thousands of Delphi based components - archivers, cyphers, audio processors etc things which people mostly like Delphi for and which seldom use specific Delphi features causing problems to FPC. That's not to write everything from scratch like with fpGUI, MSEgui etc libs far way from Delphi. Though from me experience, these thousands of components are difficult time consuming to test [thoroughly! ] choose amongst - in many cases writing from scratch is easier. Synapse vs Indy is a great example :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Am 20.08.2012 20:27, schrieb Graeme Geldenhuys: * UnicodeString is always UTF-16 (so everything but Windows takes a conversion penalty)! A decision has been made and you are not happy with it. Fine. But before you called the fpc team being in a deadlock? Many things by the FPC team get discussed or debated behind closed doors, so how are we even in the fpc-devel mailing list to know what is decided. Last I read in fpc-devel it was still heavily debated and no decision was in sight. I guess now we know, the decision is UTF-16 everywhere where UnicodeString is used. Actually, you overestimate what the FPC team can decide. The decision was more like: somebody popped up and proposed to implement Unicodestring support in a D2009+ compatible way without breaking too much legacy stuff. So we could say, ok, we merge this into fpc's svn. The alternative would have been to say no, we leave things as they are: deadlock. The current situation is: - either somebody starts to implement support for unicodestring being utf-8 (or whatever) on linux in a compatible way with the current approach, then 2.8.0 will use this - nobody works on it, then 2.8.0 comes with unicodestring=utf-16 always. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
MAm 20.08.2012 20:27 schrieb Hans-Peter Diettrich drdiettri...@aol.com: Graeme Geldenhuys schrieb: On 20/08/12 08:52, Sven Barth wrote: Just to avoid confusion: The reference counted 2-byte string type on all platforms is UnicodeString, not WideString (the latter is not reference counted on Windows platforms). Please correct me if I am wrong, but I think WideString was reference counted an all platforms in the beginning - like Martin mentioned. Later it was changed, and the new UnicodeString become the reference counted on all platforms type. WideStrings on Windows platforms are allocated in *system* space, so that they can be used across processes. Reference counting can occur only according to the Windows (COM) rules. Delphi UnicodeStrings are stored in the (local) program space instead, so that local reference counting can be used. Dunno about passing such strings to other processes, though. The point that Martin and Graeme made was that at the beginning of WideString support in the compiler (1.9.x or so...) WideString was implemented in a refcounted way like UnicodeString is today. Only later on WideString on Windows was changed to be the COM compatible string type we know from Delphi. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Hans-Peter Diettrich wrote: Mark Morgan Lloyd schrieb: I've got a couple of terminal emulators using WideChar and WideString for internal manipulation, what /should/ I be using? and where does it leave things like Sorokin's regex unit, which similarly use WideChar and WideString? Depends on which libraries you use. AFAIK SBCS RegEx works for both Ansi and UTF-8 strings, so that an UTF-16 library is optional. For the terminal emulators I'd think that it's sufficient to introduce an internal string type that allows to switch between UTF-8 and UTF-16, so that the (different?) behaviour can be tested. When there exist differences, this indicates that the WideString emulators *only* handle Unicode BMP characters, not surrogate pairs, and you have to decide whether this restriction is okay for you. I think I need to clarify. The terminal emulators are not for a standard coding such as UTF-8, but accept a non-standard byte sequence over e.g. a telnet or serial connection and convert that to a particular set of characters to emulate e.g. an IBM Selectric APL golfball. Sorokin's regex unit is a separate issue, and applies to FPC's regexpr package which uses WideChar: I don't know whether this would be problematic on Windows. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode in the RTL (my ideas)
Graeme Geldenhuys schrieb:
{$IFDEF WINDOWS}
UnicodeString = type AnsiString(CP_UTF16);
AnsiStrings consist of bytes only, for good reasons (mostly
performance). The Delphi developers wanted to implement what you
suggest, but dropped that approach later again.
String classes have the same performance problems, so that e.g. in .NET
it's suggested to use functions instead of string operators. In Delphi
and FPC compiler magic is used instead of classes.
{$ELSE}
// probably not strictly correct, but assuming *nix here. But
you get the idea
UnicodeString = type AnsiString(CP_UTF8);
{$ENDIF
String = type UnicodeString;
Char = type String[4]; // the maximum size of a Unicode codepoint
is 4 bytes
A character type is somewhat useless, unless all strings are UTF-32
(what's quite unlikely now). Instead substrings should be used, which
can contain any number of bytes or characters.
You also have to explain what String[4] means in an Unicode environment.
The ShortString type does not have an encoding, and thus is deprecated
in a Unicode environment.
Q: Did you ever read about the new string implementation of FPC?
Do you really want to reinvent the wheel, in another incompatible way?
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Ivanko B schrieb: No, Unicode is large than UCS-2. Also about your alien language comment. Unicode includes code points not just for spoken languages, but for anything that can be written. eg: musical notes, scientific symbols, advanced math symbols, map glyphs, smiley faces (can be used in in email's, IM programs etc without embedded images), braille etc They all have already been present in UCS-2, AFAIK. Do You means possible extensions in the future ? Are they really possible ? UCS2 is nowadays known as the BMP (Basic Multilingual Plane) of full Unicode. Have a look at the full Unicode codepages, what is and what is not part of the BMP. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FPC -Rintel and -alr options
Is there a way to see the generated .s assembly files as Intel syntax instead of the ATT one? The -Rintel flag does not seem to work, or I am doing something wrong. Tried command line and fpc.cfg both, on win32 and win64, latest SVN . ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC -Rintel and -alr options
On 8/20/2012 21:38, ABorka wrote: Is there a way to see the generated .s assembly files as Intel syntax instead of the ATT one? The -Rintel flag does not seem to work, or I am doing something wrong. Tried command line and fpc.cfg both, on win32 and win64, latest SVN . what command line, exactly, please? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC -Rintel and -alr options
21.08.2012 5:38, ABorka пишет: Is there a way to see the generated .s assembly files as Intel syntax instead of the ATT one? The -Rintel flag does not seem to work, or I am doing something wrong. Tried command line and fpc.cfg both, on win32 and win64, latest SVN . -R switch controls parsing assembler blocks in the code. The output format is set with -A (e.g. -Amasm will produce Intel syntax). Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
