On 09/19/2011 06:35 PM, Luiz Americo Pereira Camara wrote:
On 19/9/2011 09:47, Michael Schnell wrote:
I don't suppose Lazarus can work with a cpstrnew version of FPC at all.
Supposedly moving Lazarus to cpstrnew will be a lot of work.
Not at all. Since fpc will provide two rtl (UTF8 and
On 09/20/2011 11:09 AM, Luiz Americo Pereira Camara wrote:
Nope. AFAIK String type will automatically map to UTF8 or UTF16 string
depending of a compiler switch or directive and the RTL used (UTF8,
UTF16).
What do you mean by map to UTF8 ? AFAIK, there is no string type in
FPC that decently
2011/9/20 Michael Schnell mschn...@lumino.de:
What do you mean by map to UTF8 ? AFAIK, there is no string type in FPC
that decently denotes a dedicated encoding for the content so that library
functions know how to handle them.
You will be able to alias String for UnicodeString (UTF-16) or
On 09/20/2011 01:09 PM, cobines wrote:
String=AnsiString(CP_UTF8),
Meaning that a library function (or an FPC syntax candy feature) can't
detect the code that is used for the string.
If you mean UTF-16 UnicodeString then I don't think there will be a
problem.
AFAIK, Lazarus does not use
Am 20.09.2011 14:16, schrieb Michael Schnell:
On 09/20/2011 01:09 PM, cobines wrote:
String=AnsiString(CP_UTF8),
Meaning that a library function (or an FPC syntax candy feature) can't
detect the code that is used for the string.
Huh? What do you mean here? If String is declared as a
2011/9/20 Michael Schnell mschn...@lumino.de:
On 09/20/2011 01:09 PM, cobines wrote:
String=AnsiString(CP_UTF8),
Meaning that a library function (or an FPC syntax candy feature) can't
detect the code that is used for the string.
The code page will be stored in the record describing the
On 09/20/2011 02:41 PM, Sven Barth wrote:
Huh? What do you mean here? If String is declared as a
AnsiString(CP_UTF8) then the a variable declared as String does
contain UTF8 data... and any code can detect that by using GetCodePage
which will return CP_UTF8.
Ah, I see. He was meaning a New
Sorry, I suppose I misunderstood one of your previous messages.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
2011/9/20 Michael Schnell mschn...@lumino.de:
Sorry, I suppose I misunderstood one of your previous messages.
IMHO, almost every message in thread after the first couple of
messages is premature, since nothing has been decided for the string
extension is fpc 2.7.1. There everything said about
Am 20.09.2011 15:46, schrieb Vincent Snijders:
2011/9/20 Michael Schnellmschn...@lumino.de:
Sorry, I suppose I misunderstood one of your previous messages.
IMHO, almost every message in thread after the first couple of
messages is premature, since nothing has been decided for the string
2011/9/20 Sven Barth pascaldra...@googlemail.com:
But at least we have the new code page aware string in trunk now, so the
recent Unicode discussions were worth something :P
Paul, is that true? Did the recent Unicode discussions on this list
and the fpc lists help you / motivate you to work on
Am 20.09.2011 16:02, schrieb Vincent Snijders:
2011/9/20 Sven Barthpascaldra...@googlemail.com:
But at least we have the new code page aware string in trunk now, so the
recent Unicode discussions were worth something :P
Paul, is that true? Did the recent Unicode discussions on this list
and
20.09.2011 22:02, Vincent Snijders wrote:
2011/9/20 Sven Barthpascaldra...@googlemail.com:
But at least we have the new code page aware string in trunk now, so the
recent Unicode discussions were worth something :P
Paul, is that true? Did the recent Unicode discussions on this list
and the fpc
Am 20.09.2011 16:18, schrieb Paul Ishenin:
20.09.2011 22:02, Vincent Snijders wrote:
2011/9/20 Sven Barthpascaldra...@googlemail.com:
But at least we have the new code page aware string in trunk now, so the
recent Unicode discussions were worth something :P
Paul, is that true? Did the recent
On Mon, Sep 19, 2011 at 02:47:35PM +0200, Michael Schnell wrote:
What problems could it cause, is it because Lazarus currently uses
AnsiString as UTF8?
I don't suppose Lazarus can work with a cpstrnew version of FPC at all.
Supposedly moving Lazarus to cpstrnew will be a lot of work.
2011/9/19 Paul Ishenin webpi...@mail.ru:
Lazarus must use either UTF8String everywhere or nowhere.
I thought that Lazarus will continue to use UTF-8 on all platforms and
String will mean String65001 and it will be interchangeable with
UTF8String. Is that not so?
Why change UTF8String to
19.09.2011 17:06, cobines wrote:
2011/9/19 Paul Isheninwebpi...@mail.ru:
Lazarus must use either UTF8String everywhere or nowhere.
I thought that Lazarus will continue to use UTF-8 on all platforms and
String will mean String65001 and it will be interchangeable with
UTF8String. Is that not
Thank you, I think I understand it now. Currently in Lazarus String =
AnsiString and by default it has DefaultSystemCodePage. If I use
UTF8String type than it is AnsiString(CP_UTF8). So, to avoid
conversions, which Lazarus does not want, I also need to remove usage
of UTF8String from my
19.09.2011 18:32, cobines wrote:
My confusion was caused by the fact that Lazarus uses AnsiString with
default system code page but inside it always stores UTF-8, sort of
fooling the compiler. Is this correct? If so, is it not possible to
set Lazarus to use String=AnsiString(CP_UTF8) by default?
2011/9/19 Paul Ishenin webpi...@mail.ru:
This is not desired at the moment because compiler is not 100% ready to use
UTF8String.
When compiler support for cp strings is ready Lazarus will probably switch
to UTF8String type.
I see, so the removal of UTF8String is sort of a workaround for
Paul Ishenin schrieb:
Why not apply the same to AnsiString and change all to String since
Lazarus does not work with Ansi code pages anyway?
Lazarus works with strings which have 1 byte per element. If FPC later
switch default string type to UnicodeString Lazarus will suddenly get
many
19.09.2011 20:05, Hans-Peter Diettrich wrote:
Compiler adds implicit codepage conversion for string arguments. I
had to avoid that. The better choise would be to use RawByteString
type but I it is not defined in fpc 2.4.4 which we need to support.
IMO the use of RawByteString will not help
On 09/18/2011 04:22 PM, cobines wrote:
Hello.
Yesterday there was a commit:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revroot=lazarusrevision=32374
don't use UTF8String type in the code. It will cause problems when
cpstrenew branch is merged
What problems could it cause, is it
Am 19.09.2011 14:47, schrieb Michael Schnell:
On 09/18/2011 04:22 PM, cobines wrote:
Hello.
Yesterday there was a commit:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revroot=lazarusrevision=32374
don't use UTF8String type in the code. It will cause problems when
cpstrenew branch is
On 19/9/2011 08:19, Paul Ishenin wrote:
19.09.2011 20:05, Hans-Peter Diettrich wrote:
IMO the use of RawByteString will not help much, except for
(possibly) simpler code and less overloaded procedures. Avoiding
implicit conversions instead will require *fixed* string types and
encodings, for
On 19/9/2011 09:47, Michael Schnell wrote:
I don't suppose Lazarus can work with a cpstrnew version of FPC at all.
Supposedly moving Lazarus to cpstrnew will be a lot of work.
Not at all. Since fpc will provide two rtl (UTF8 and UTF16) Lazarus
should work without much changes with the UTF8
On 19/9/2011 13:31, Luiz Americo Pereira Camara wrote:
Regarding change to UTF8ToUTF16 function RawByteString should not be
used.
BTW: as soon the new string type is used, UTF8ToUTF16 and alikes will
not be necessary at all
Luiz
--
___
Lazarus
Hello.
Yesterday there was a commit:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revroot=lazarusrevision=32374
don't use UTF8String type in the code. It will cause problems when
cpstrenew branch is merged
What problems could it cause, is it because Lazarus currently uses
AnsiString as
18.09.2011 22:22, cobines wrote:
don't use UTF8String type in the code. It will cause problems when
cpstrenew branch is merged
Lazarus must use either UTF8String everywhere or nowhere.
We are using UTF8String in our application just for the sake of
denoting that it is UTF8 encoding not Ansi.
29 matches
Mail list logo
