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 with
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
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.
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 -
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
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
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
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
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 Strings.)
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 merged
On Monday, September 9, 2013 8:41 AM, Michael Schnell mschn...@lumino.de
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
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
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
On 06.09.2013 22:48, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
Am 06.09.2013 14:16 schrieb Hans-Peter Diettrich
drdiettri...@aol.com 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:
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
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
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
Am 07.09.2013 17:23 schrieb Hans-Peter Diettrich drdiettri...@aol.com:
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
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
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
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
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
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
Am 06.09.2013 14:16 schrieb Hans-Peter Diettrich 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
result back to CP_ACP. In these cases it looks more efficient to call the
Unicode
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: while the
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 it
Sven Barth schrieb:
Am 06.09.2013 14:16 schrieb Hans-Peter Diettrich drdiettri...@aol.com
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 result back to CP_ACP. In
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:
28 matches
Mail list logo
