On Sat, 5 Jan 2013, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
On Sat, 5 Jan 2013, Jonas Maebe wrote:
On 05 Jan 2013, at 12:53, Paul Ishenin wrote:
ResourceStrings are stored as AnsiString type with 0 codepage (as I
remember). Delphi now stores ResourceStrings as UnicodeString type. I
think FPC will follow this in m_default_unicodestring modeswitch.
It would probably even be better to always do that. At least I don't see a
downside, other than slightly larger binaries (and that's not an issue in
this case as far as I'm concerned; maintaining two separate resourcestring
systems/handlers is just not worth the trouble).
But it means that for
Resourcestring
AString = 'Something';
Var
S : Ansistring;
begin
S:=AString;
end.
Always a conversion will happen.
I do not think this is a good idea given that currently, String =
Ansistring.
IMO resource strings are for display purposes, so that UTF-8/16 encoding is
expected by an OS API. AFAIR Win32 string resources are stored in UTF-16,
You are very much wrong.
To start with, resource strings are not stored as Win32 resources.
Secondly, they are stored in the code as an ansistring.
The resource string of the above example is stored as:
.globl _$PROGRAM$_Ld2
_$PROGRAM$_Ld2:
.ascii "Something\000"
.balign 8
.short 0,1
.long 0
.quad -1,15
.globl _$PROGRAM$_Ld3
Thirdly: in my apps, no UTF-8/16 encoding is expected by the OS.
If it were, I would have used widestrings instead of ansistring
to begin with, and in that case I would not have made any remark...
So the conversion really would be 100% totally redundant.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel