Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On 09/10/2013 02:25 AM, wkitt...@windstream.net wrote: speaking of conversions, i would also like to see where UTF8 and similar strings can convert to (eg) CP437 where UTF characters like the trademark symbol are converted to their CP437 four character equivalent (eg) "(tm)"... registered and c

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On 09/10/2013 02:25 AM, wkitt...@windstream.net wrote: i agree... ANSIstrings should be ANSI only... UTF8string and UTF16string should be available and used where necessary, And the "NewStrings" that can (defined statically and - if compiler magic is done accordingly - dynamically) be used wit

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On Monday, September 9, 2013 8:41 AM, Michael Schnell wrote: > I feel like throwing up when I am supposed to use the Term ANSIString > for things potentially being encoded as UTF-8, UTF-16 or such, which > for me is the contrary of "ANSI". i agree... ANSIstrings should be ANSI only... UTF8

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

In our previous episode, Michael Schnell said: > in the topic by the OP ? > > (I seem to remember when the project started it was called something > like "cpstrnew" which I interpreted as "new Delphi Strings".) cpstrnew is the new ansistring type and was merged long ago. Last week cpstrrtl was

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On 09/09/2013 02:34 PM, Sven Barth wrote: Please get your terms right Sorry for my ignorance, but what in detail is "cpstr" which is mentioned in the topic by the OP ? (I seem to remember when the project started it was called something like "cpstrnew" which I interpreted as "new Delphi Strin

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On 09/09/2013 02:34 PM, Sven Barth wrote: Please get your terms right You are right I always are unsure about the correct terms here. I feel like throwing up when I am supposed to use the Term ANSIString for things potentially being encoded as UTF-8, UTF-16 or such, which for me is the contr

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Am 09.09.2013 14:25, schrieb Michael Schnell: On 09/07/2013 03:00 PM, Sven Barth wrote: We do NOT want to force UnicodeString upon every target. The world not only consists of Windows! +1 ! Of course a compiler switch to not use the "NewStrings" would be appropriate. OTOH IMHO it should

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On 09/07/2013 03:00 PM, Sven Barth wrote: We do NOT want to force UnicodeString upon every target. The world not only consists of Windows! +1 ! Of course a compiler switch to not use the "NewStrings" would be appropriate. OTOH IMHO it should be possible to in fact use the "NewStrings" in

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On 09/07/2013 05:22 PM, Hans-Peter Diettrich wrote: 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? IMHO ( :-) :-) ) specially typed Strings are _very_

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On 09/06/2013 06:30 PM, Sven Barth wrote: Not every RTL will use a 16-bit API. These RTL/LCL functions / procedures / properties would be covered by the case "B1" in my post a little earlier in this thread.. -Michael ___ fpc-devel maillist - fpc

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On 09/06/2013 03:59 PM, Hans-Peter Diettrich wrote: You defer the problem from the interface to the implementation. When a procedure has an string parameter of an unknown encoding, the implementation must check every time the *current* encoding of the parameter, and proceed as appropriate. IM

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On 07.09.2013 23:00, Hans-Peter Diettrich wrote: Sven Barth schrieb: > Sorry, I didn't look at or step through the generated code. I still > doubt that a concatenation function gets an TargetEncoding argument. The target string is passed as var-parameter and thus the codepage can be queried

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Sven Barth schrieb: > Sorry, I didn't look at or step through the generated code. I still > doubt that a concatenation function gets an TargetEncoding argument. The target string is passed as var-parameter and thus the codepage can be queried using StringCodePage. See fpc_ansistr_concat in

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Am 07.09.2013 17:23 schrieb "Hans-Peter Diettrich" : 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

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Hans-Peter Diettrich schrieb: 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). Correction: only test(a) is accepted. DoDi ___ fpc-devel maillist

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

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 d

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On 07.09.2013 01:39, Hans-Peter Diettrich wrote: I'm not sure how efficient a RawByteString version ever can be. By default it has to convert the string into Unicode (Delphi: UTF-16), No, see Sven's answer. You can safely remove the RawByteString versions, when the compiler-generated convers

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On 06.09.2013 22:48, Hans-Peter Diettrich wrote: Sven Barth schrieb: Am 06.09.2013 14:16 schrieb "Hans-Peter Diettrich" mailto:drdiettri...@aol.com>>: > I'm not sure how efficient a RawByteString version ever can be. By default it has to convert the string into Unicode (Delphi: UTF-16), and the

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

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 t

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Jonas Maebe schrieb: On 06 Sep 2013, at 13:54, Hans-Peter Diettrich wrote: Jonas Maebe schrieb: o merged cpstrrtl branch (includes unicode branch). In general, this adds support for arbitrarily encoded ansistrings to many routines related to file system access (and some others). WARNING: whil

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Sven Barth schrieb: Am 06.09.2013 14:16 schrieb "Hans-Peter Diettrich" >: > I'm not sure how efficient a RawByteString version ever can be. By default it has to convert the string into Unicode (Delphi: UTF-16), and the result back to CP_ACP. In these cases it looks

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On 06 Sep 2013, at 23:13, Jonas Maebe wrote: > I think we could actually introduce a global variable in the system unit that > changes the behaviour of b) to "the result will have a code page that can > represent all characters from the concatenated strings", which by default is > off. Turning

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On 06 Sep 2013, at 13:54, Hans-Peter Diettrich wrote: > Jonas Maebe schrieb: >> o merged cpstrrtl branch (includes unicode branch). In general, this adds >>support for arbitrarily encoded ansistrings to many routines related to >>file system access (and some others). >> WARNING: whi

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Am 06.09.2013 14:16 schrieb "Hans-Peter Diettrich" : > I'm not sure how efficient a RawByteString version ever can be. By default it has to convert the string into Unicode (Delphi: UTF-16), and the result back to CP_ACP. In these cases it looks more efficient to call the Unicode version immediately

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Michael Schnell schrieb: Of course I need to jump in here ... Of course ;-) While I don't exactly know what you are up to, you might want to read some recent posts of mine where I pointed out that using a fully dynamically encoding auto-converting String type (which does not seem to exist

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On 09/06/2013 01:54 PM, Hans-Peter Diettrich wrote: I'm not sure how efficient a RawByteString version ever can be. By default it has to convert the string into Unicode (Delphi: UTF-16), and the result back to CP_ACP. In these cases it looks more efficient to call the Unicode version immediately

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On 09/06/2013 01:54 PM, Hans-Peter Diettrich wrote: I'm not sure how efficient a RawByteString version ever can be. By default it has to convert the string into Unicode (Delphi: UTF-16), and the result back to CP_ACP. In these cases it looks more efficient to call the Unicode version immediat

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Jonas Maebe schrieb: Hi, I've just merged the cpstrrtl/unicode branch into trunk. Below you can find the commit message, which describes most changes, the added features and also a very important warning. Jonas o merged cpstrrtl branch (includes unicode branch). In general, this adds

[fpc-devel] cpstrrtl/unicode branch merged to trunk

Hi, I've just merged the cpstrrtl/unicode branch into trunk. Below you can find the commit message, which describes most changes, the added features and also a very important warning. Jonas o merged cpstrrtl branch (includes unicode branch). In general, this adds support for arbitrarily