Jonas Maebe schrieb:
On 07 Sep 2013, at 01:39, Hans-Peter Diettrich wrote:
Jonas Maebe schrieb:
On 06 Sep 2013, at 13:54, Hans-Peter Diettrich wrote:
That conversion IMO is done by the every concatenation, apart
from subroutine considerations.
I think you mean "afaik" rather than "IMO".
I don't talk about concrete code, so I cannot know anything.
"In my opinion" means "I know the facts, and this is my opinion about
those facts". "As far as I know" means "to the extent of my (possibly
limited/incomplete/wrong) knowledge" or, more or less, "I
think/believe".
Hmm, that turns my understanding upside down.
Anyway, the resulting code page of a concatenation is normally
the code page of whatever you assign the string to (so if you
assign to an utf8string, the resulting code page will be
CP_UTF8).
Maybe. I don't know how a concrete compiler handles string
concatenations.
Now you do. It's like that both in FPC and in Delphi.
Sorry, I didn't look at or step through the generated code. I still
doubt that a concatenation function gets an TargetEncoding argument.
Delphi has overloaded functions for RawByteString and
AnsiString(0).
Does this really compile in Delphi?
It compiles, of course.
I think that a "can't decide which overloaded function to call" error
would be just as logical.
You are right, all calls are ambiguous except test(b).
Please look at and/or test the FPC code, then present your findings
about what is actually implemented for FPC.
Later, perhaps, actually I'm busy with other projects.
The DefaultFileSystemCodePage only exists to ensure that a) no
data is lost between you giving a string to an RTL routine and
calling a single byte OS API b) file names returned by single
byte OS APIs are correctly handled/interpreted by the RTL and get
their code page set correctly
So why do you only specify a codepage, without also declaring an
accordingly encoded string type? Such a type would allow for
automatic conversion (if ever required) of file/directory name
arguments in RTL functions. Which string type would you use for
such arguments?
All of those routines return a "RawByteString". You can assign such a
string to any ansistring type (including a plain ansistring) and the
compiler will not insert any kind of code page conversion (and the
string's code page will also remain the same, even if it is different
from the declared code page of the string you assigned the value to).
This means that any AnsiString variable can contain any encoding, not
only the declared one? What's the purpose of specially typed AnsiStrings
then, and the difference vs. RawByteString?
DoDi
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
