Is there a known issue on Mac?
The following was observed on 2 different 32 bit Mac:
compiling from lazarus tests/lazutils/testunicode.lpi
with -gs / also entire LCL compiled with -gs / standard fpc 2.4.4
installation (I would assume that does not have dwarf? but I do not know)
info line
"/
Hello,
Posting here as this was requested in the bug report:
http://bugs.freepascal.org/view.php?id=20473
I think it is very simple: Having such a directive would save a lot of
work when porting Lazarus-based projects to FPC 2.7
--
Felipe Monteiro de Carvalho
___
Am 13.10.2011 04:30, schrieb Hans-Peter Diettrich:
Martin Schreiber schrieb:
Well, with Delphi 2009's Unicode support, the Delphi language now
supports Unicode too. Thus unit names, class names, property names,
variable names etc can all contain Unicode text in there names. So yes,
Unicode is r
On 10/13/2011 02:16 AM, Hans-Peter Diettrich wrote:
Almost every required conversion can be determined at compile time.
It also _can_ be determined at runtime according to the current encoding
ID of the string(s)
This discussion is not about "can" but about "is" and maybe "should be".
Moreov
Am 13.10.2011 09:29, schrieb Felipe Monteiro de Carvalho:
Hello,
Posting here as this was requested in the bug report:
http://bugs.freepascal.org/view.php?id=20473
I think it is very simple: Having such a directive would save a lot of
work when porting Lazarus-based projects to FPC 2.7
1. Cu
13.10.2011 15:29, Felipe Monteiro de Carvalho пишет:
Hello,
Posting here as this was requested in the bug report:
http://bugs.freepascal.org/view.php?id=20473
I think it is very simple: Having such a directive would save a lot of
work when porting Lazarus-based projects to FPC 2.7
Wrote to t
Am 13.10.2011 09:49, schrieb Michael Schnell:
Moreover seemingly there is (or will be, or in Delphi XE is) a type
called UnicodeString. In the Delphi docs UnicodeString is said to be
supposed to hold UTF-16 encoded data. But this of course is due to the
string Windows-Binding of Delphi. On Linux
On 10/13/2011 02:05 AM, Hans-Peter Diettrich wrote:
- assignment will do a conversion (at least if the target encoding
ID is not zero.)
... conversion unless the target type is RawByteString, or has the
same encoding.
Paul did inform us that encoding ID = 0 in the target means no
conversion
On 13 Oct 2011, at 09:30, Sven Barth wrote:
Am 13.10.2011 04:30, schrieb Hans-Peter Diettrich:
Perhaps it's an attempt to better interface with .NET, Java or
ObjectiveC?
I don't think so as AFAIK all three don't support unicode characters
in identifiers.
Java does, but the JDK doesn't c
On 13 Oct 2011, at 09:28, Martin wrote:
same address when trying to insert a breakpoint
-break-insert -f testunicode.pas:182
^done,bkpt={number="11",type="breakpoint",disp="keep",enabled="y",addr="0x0edb",file="testunicode.pas",line="182",shlib="/Users/felipe/Programas/lazarus/test/lazutil
Am 13.10.2011 09:56, schrieb Jonas Maebe:
On 13 Oct 2011, at 09:30, Sven Barth wrote:
Am 13.10.2011 04:30, schrieb Hans-Peter Diettrich:
Perhaps it's an attempt to better interface with .NET, Java or
ObjectiveC?
I don't think so as AFAIK all three don't support unicode characters
in identif
On 10/13/2011 04:27 AM, Hans-Peter Diettrich wrote:
FireMonkey is a third-party product, now bought by Embarcadero. That
deal seems to be an attempt to avoid an own development, what already
failed with both Kylix and Delphi.NET.
instead of Kylix they now with XE2 provide FPC and instead of Delp
In our previous episode, Michael Schnell said:
> > deal seems to be an attempt to avoid an own development, what already
> > failed with both Kylix and Delphi.NET.
> instead of Kylix they now with XE2 provide FPC and instead of Delphi.NET
> they sell Prism. Both are 3rd party products, too.
No, t
On 10/13/2011 04:27 AM, Hans-Peter Diettrich wrote:
I don't see a speed penalty in using UTF-16. In contrast to UTF-8 it
simplifies (and consequently speeds up) all string handling.
If doing code heavily doing GUI handling (such as the LCL in Lazarus)
and the GUI's API is not UTF-16, all str
On 10/13/2011 10:11 AM, Marco van de Voort wrote:
No, they stated the FPC usage was only temporary because their own ARM
compiler was delayed.
but AFAIK not notion on until when
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
ht
On Thu, Oct 13, 2011 at 9:43 AM, Sven Barth wrote:
> 1. Currently there is this huge work going on to get trunk to a reasonable
> and usable shape again and until that is done (and maybe RTL changes as
> well) it is (in my opinion (!) ) not reasonable to think about changing the
> meaning of "stri
On Thu, Oct 13, 2011 at 9:44 AM, Paul Ishenin wrote:
> The later can be made by call SetMultiByteConversionCodePage(CP_UTF8) at the
> program start.
>From my comment on the bug report:
Won't SetMultyByteConversionCodePage inadvertedly affect 3rd party
libraries used by the program which, for exa
Hello,
Then maybe the default debug info created by -g on Mac should be
dwarf2? dwarf2 works correctly in my tests.
Is there a table somewhere about which debug info types are default in
each operating system?
--
Felipe Monteiro de Carvalho
___
fpc-de
In our previous episode, Felipe Monteiro de Carvalho said:
> RTLString = string;
>
> It would not need to be used anywhere in the RTL, but files which use
> the utf8string directive can use this string type to reffer to the RTL
> string type.
How do you override classes that are declared in RTLSt
On 10/13/2011 03:13 AM, Hans-Peter Diettrich wrote:
..., or try to implement something incompatible with Delphi :-(
I would not generally depreciate this.
I heard a lot comments on problems introduced by the Delphi Unicode
String implementation. So maybe in fact there is room for (incompatibl
On 10/13/2011 08:20 AM, Paul Ishenin wrote:
RawByteString codepage. Value $ and purpose - inform that string
has no codepage assigned. I think at the moment compiler does not
produce strings of codepage $ anymore but before it did. So now we
can probably clear the RTL from this codepa
On Thu, Oct 13, 2011 at 10:17 AM, Marco van de Voort wrote:
> How do you override classes that are declared in RTLString which might not
> be equal to utf8string?
I dont fully understand your question, but lets suppose this RTL file:
unit system;
{$mode string = banana}
type RTLString = string;
13.10.2011 16:14, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 9:44 AM, Paul Ishenin wrote:
The later can be made by call SetMultiByteConversionCodePage(CP_UTF8) at the
program start.
From my comment on the bug report:
Won't SetMultyByteConversionCodePage inadvertedly affect
On Thu, Oct 13, 2011 at 10:26 AM, Paul Ishenin wrote:
> It will affect as well as compiler directive you suggested to add.
No, the directive is per source code file. 3rd party libraries do not
need to use it.
--
Felipe Monteiro de Carvalho
___
fpc-dev
On 10/13/2011 09:43 AM, Sven Barth wrote:
1. Currently there is this huge work going on to get trunk to a
reasonable and usable shape again and until that is done (and maybe
RTL changes as well) it is (in my opinion (!) ) not reasonable to
think about changing the meaning of "string" at all.
13.10.2011 11:30, Sven Barth пишет:
Am 13.10.2011 04:30, schrieb Hans-Peter Diettrich:
Martin Schreiber schrieb:
Well, with Delphi 2009's Unicode support, the Delphi language now
supports Unicode too. Thus unit names, class names, property names,
variable names etc can all contain Unicode text
On 13 Oct 2011, at 10:17, Felipe Monteiro de Carvalho wrote:
Then maybe the default debug info created by -g on Mac should be
dwarf2? dwarf2 works correctly in my tests.
Yes, I agree it's about time to change that (along with making -
godwarfsets the default). It requires at least the latest
Am 13.10.2011 10:39, schrieb Michael Schnell:
The last FPC version I installed was "Free Pascal Compiler version 2.7.1
[2011/08/26] for i386". "/usr/bin/ppc383" points to
"../lib/fpc/2.7.1/ppc386".
So, when installing a Unicode enabled it might be a good idea to do this
to a separate subdirector
On 13 Oct 2011, at 10:37, Jonas Maebe wrote:
On 13 Oct 2011, at 10:17, Felipe Monteiro de Carvalho wrote:
Then maybe the default debug info created by -g on Mac should be
dwarf2? dwarf2 works correctly in my tests.
Yes, I agree it's about time to change that (along with making -
godwarfset
On 10/13/2011 09:47 AM, Sven Barth wrote:
Since FPC 2.4 there also is a UnicodeString in FPC which is compatible
to the one in Delphi: a reference counted 2-byte-per-character string
type.
So you suggest that in Delphi XE, UnicodeString is _not_ a "new String"
Type ?
-Michael
__
In our previous episode, Felipe Monteiro de Carvalho said:
> I dont fully understand your question, but lets suppose this RTL file:
>
> unit system;
> {$mode string = banana}
> type RTLString = string;
>
> unit classes;
> {$mode string = banana}
> type
> TWhaeverClass = class
> procedure Do(P
Am 13.10.2011 10:34, schrieb Alex Shishkin:
13.10.2011 11:30, Sven Barth пишет:
Am 13.10.2011 04:30, schrieb Hans-Peter Diettrich:
Martin Schreiber schrieb:
Well, with Delphi 2009's Unicode support, the Delphi language now
supports Unicode too. Thus unit names, class names, property names,
va
On 10/13/2011 10:39 AM, Sven Barth wrote:
When installing you can always select a custom directory though you
can not change the version-id. E.g. you could install to
"/lib/fpc-cpstring/2.7.1".
Of course I do know how to install FPC in another directory or how to
preserve the current installa
Am 13.10.2011 10:46, schrieb Michael Schnell:
On 10/13/2011 09:47 AM, Sven Barth wrote:
Since FPC 2.4 there also is a UnicodeString in FPC which is compatible
to the one in Delphi: a reference counted 2-byte-per-character string
type.
So you suggest that in Delphi XE, UnicodeString is _not_ a
On 10/13/2011 10:52 AM, Sven Barth wrote:
So you suggest that in Delphi XE, UnicodeString is _not_ a "new String"
Type ?
I don't know what you describe as "new string", but "UnicodeString"
was introduced as a new type in Delphi 2009 and "String" was made an
alias to "UnicodeString". If you
On Thu, Oct 13, 2011 at 10:47 AM, Marco van de Voort wrote:
> But I don't consider this as solution. You have to put each string type in
> the entire libraries on trial, and keep it up.
Could you explain more? Which libraries are you talking about? As I
showed, nothing would need to change in the
Michael Schnell hat am 13. Oktober 2011 um 10:18
geschrieben:
> On 10/13/2011 04:27 AM, Hans-Peter Diettrich wrote:
> >
> > I don't see a speed penalty in using UTF-16. In contrast to UTF-8 it
> > simplifies (and consequently speeds up) all string handling.
>
> If doing code heavily doing G
Am 13.10.2011 11:04, schrieb Michael Schnell:
On 10/13/2011 10:52 AM, Sven Barth wrote:
So you suggest that in Delphi XE, UnicodeString is _not_ a "new String"
Type ?
I don't know what you describe as "new string", but "UnicodeString"
was introduced as a new type in Delphi 2009 and "String"
On 10/13/2011 11:05 AM, Mattias Gaertner wrote:
LCL backends work in UTF-16.
Of course the LCL backends close to the OS-API on Windows use UTF-16, as
this is what the API provides. (Or did I misunderstand your wording ?)
-Michael
___
fpc-devel mail
On 10/13/2011 11:19 AM, Sven Barth wrote:
No, UnicodeString is not codepage aware.
I was asking about the implementation in XE.
If you mean this: Thanks for the clarification.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://
Am 13.10.2011 11:02, schrieb Felipe Monteiro de Carvalho:
On Thu, Oct 13, 2011 at 10:47 AM, Marco van de Voort wrote:
But I don't consider this as solution. You have to put each string type in
the entire libraries on trial, and keep it up.
Could you explain more? Which libraries are you talki
Am 13.10.2011 11:27, schrieb Michael Schnell:
On 10/13/2011 11:05 AM, Mattias Gaertner wrote:
LCL backends work in UTF-16.
Of course the LCL backends close to the OS-API on Windows use UTF-16, as
this is what the API provides. (Or did I misunderstand your wording ?)
AFAIK it was remarked th
Am 13.10.2011 11:29, schrieb Michael Schnell:
On 10/13/2011 11:19 AM, Sven Barth wrote:
No, UnicodeString is not codepage aware.
I was asking about the implementation in XE.
If you mean this: Thanks for the clarification.
Yes, I meant this. Only AnsiString is code page aware in Delphi 2009+
On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
wrote:
> I think he ment that if such a feature is introduced it would be a natural
> conclusion to define "string = unicodestring" on Windows and "string =
> utf8string" for Unix in the RTL and the FCL
? I am totally lost as to what this has to do wit
On Thu, 13 Oct 2011, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
wrote:
I think he ment that if such a feature is introduced it would be a natural
conclusion to define "string = unicodestring" on Windows and "string =
utf8string" for Unix in the RTL and th
In our previous episode, Felipe Monteiro de Carvalho said:
[ Charset ISO-8859-1 unsupported, converting... ]
> On Thu, Oct 13, 2011 at 10:47 AM, Marco van de Voort wrote:
> > But I don't consider this as solution. You have to put each string type in
> > the entire libraries on trial, and keep it u
On Thu, Oct 13, 2011 at 11:26 AM, Sven Barth
wrote:
> AFAIK it was remarked that Qt and Carbon (or only Cocoa?) use UTF-16 as
> well.
Carbon and Cocoa are rather encoding agnostic, but from what I
understand they use UTF-8 internally.
Qt is also rather agnostic, but internally I think it uses UT
On Thu, Oct 13, 2011 at 11:34 AM, wrote:
> In short, you want a directive to say
> "In this unit, 'string' means MyNiceStringType"
> Which is in fact an extension of the current {$H} to a more general case ?
yes
--
Felipe Monteiro de Carvalho
___
fp
On Thu, Oct 13, 2011 at 11:38 AM, Felipe Monteiro de Carvalho
wrote:
> On Thu, Oct 13, 2011 at 11:34 AM, wrote:
>> In short, you want a directive to say
>> "In this unit, 'string' means MyNiceStringType"
>> Which is in fact an extension of the current {$H} to a more general case ?
>
> yes
Actu
12.10.2011 15:29, Alex Shishkin пишет:
My proposed changes to spstring.
1) if string is defined w/o explicit encoding (f.e. just "string", in
H+ modeswitch or "ansistring") it treated as RawByteString.
2) In unicode Delphi mode encoding of all string constant values is
forced to UTF16, source en
On Thu, 13 Oct 2011, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 11:38 AM, Felipe Monteiro de Carvalho
wrote:
On Thu, Oct 13, 2011 at 11:34 AM, wrote:
In short, you want a directive to say
"In this unit, 'string' means MyNiceStringType"
Which is in fact an extension of the
On 13 Oct 2011, at 11:37, Felipe Monteiro de Carvalho wrote:
Carbon and Cocoa are rather encoding agnostic, but from what I
understand they use UTF-8 internally.
It's not documented what they use internally, but since all CFString
(= NSString) "character" accessors are UTF-16 based, I think
On Thu, Oct 13, 2011 at 11:45 AM, wrote:
> Well, if we add such a beast, it won't be just for UTF-8.
>
> Lazarus happens to be UTF-8 centric, but that doesn't mean we should limit
> the use of such a feature to UTF-8...
An addendum to that: We also need the normal PChar. Changing PChar was
*very
Am 13.10.2011 11:28, schrieb Felipe Monteiro de Carvalho:
On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
wrote:
I think he ment that if such a feature is introduced it would be a natural
conclusion to define "string = unicodestring" on Windows and "string =
utf8string" for Unix in the RTL and th
On Thu, Oct 13, 2011 at 11:51 AM, Sven Barth
wrote:
> In one of your mails you had the example of the units "system" and "classes"
> which define "string" as aliased to the string type "banana"
Ah, that was not ment to be interpreted like that ... I just wanted to
say that in this RTL mode or wha
13.10.2011 13:34, michael.vancann...@wisa.be пишет:
On Thu, 13 Oct 2011, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
wrote:
I think he ment that if such a feature is introduced it would be a
natural
conclusion to define "string = unicodestring" on Windows
Am 13.10.2011 11:49, schrieb Felipe Monteiro de Carvalho:
On Thu, Oct 13, 2011 at 11:45 AM, wrote:
Well, if we add such a beast, it won't be just for UTF-8.
Lazarus happens to be UTF-8 centric, but that doesn't mean we should limit
the use of such a feature to UTF-8...
An addendum to that: W
In our previous episode, Sven Barth said:
> I think he ment that if such a feature is introduced it would be a
> natural conclusion to define "string = unicodestring" on Windows and
> "string = utf8string" for Unix in the RTL and the FCL (and maybe "string
> = ansistring" for DOS and OS/2). Thus
Am 13.10.2011 11:53, schrieb Alex Shishkin:
another alternative. in {$H-} no changes string=shortstring, in {$h+}
string = ansistring or unocodestring in delphiunicode mode) by default
but can be redefined directly in code (or this definition is set in
ObjPas unit) "type string = MyNiceStringType
On 13/10/2011 09:37, Jonas Maebe wrote:
Is there a table somewhere about which debug info types are default in
each operating system?
No, and such table will not be made because it's an implementation
detail. If you require a particular debug information format, specify
it. Anything else wi
On Thu, 13 Oct 2011, Alex Shishkin wrote:
13.10.2011 13:34, michael.vancann...@wisa.be пишет:
On Thu, 13 Oct 2011, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
wrote:
I think he ment that if such a feature is introduced it would be a
natural
conclusion
On 13 Oct 2011, at 12:00, Martin wrote:
On 13/10/2011 09:37, Jonas Maebe wrote:
No, and such table will not be made because it's an implementation
detail. If you require a particular debug information format,
specify it. Anything else will break as soon as the default is
changed from on
In our previous episode, Martin said:
> > it. Anything else will break as soon as the default is changed from
> > one compiler version to another.
> >
> But maybe a switch could be added, where an fpc exe gives feedback, what
> it currently defaults to?
in the case of the multiple RTL situation,
Am 13.10.2011 11:57, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
I think he ment that if such a feature is introduced it would be a
natural conclusion to define "string = unicodestring" on Windows and
"string = utf8string" for Unix in the RTL and the FCL (and maybe "str
On Thu, 13 Oct 2011, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
I think he ment that if such a feature is introduced it would be a
natural conclusion to define "string = unicodestring" on Windows and
"string = utf8string" for Unix in the RTL and the FCL (and maybe "st
On Thu, 13 Oct 2011, Sven Barth wrote:
Am 13.10.2011 11:57, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
I think he ment that if such a feature is introduced it would be a
natural conclusion to define "string = unicodestring" on Windows and
"string = utf8string" for
On 10/13/2011 11:45 AM, michael.vancann...@wisa.be wrote:
Lazarus happens to be UTF-8 centric
I understand, this is because it had been impossible for them to support
as well UTF-8 for Linux as UTF-16 for Windows,
With the new code page aware Strings it should be possible to compile
the sa
In our previous episode, Sven Barth said:
> > the utf* designates the type of the default string type. And the same for
> > unix. Maybe win32-ansi too.
>
> Ok... that you want multiple distributions per platform is clear now.
> But you would not oppose (in the case of having multiple distributio
Am 13.10.2011 12:13, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
the utf* designates the type of the default string type. And the same for
unix. Maybe win32-ansi too.
Ok... that you want multiple distributions per platform is clear now.
But you would not oppose (in t
Paul Ishenin schrieb:
What's CP_NONE? Value and purpose?
RawByteString codepage. Value $ and purpose - inform that string has
no codepage assigned. I think at the moment compiler does not produce
strings of codepage $ anymore but before it did. So now we can
probably clear the RTL f
Marco van de Voort schrieb:
In our previous episode, Michael Schnell said:
deal seems to be an attempt to avoid an own development, what already
failed with both Kylix and Delphi.NET.
instead of Kylix they now with XE2 provide FPC and instead of Delphi.NET
they sell Prism. Both are 3rd party pr
On 13 Oct 2011, at 12:06, Marco van de Voort wrote:
In our previous episode, Martin said:
But maybe a switch could be added, where an fpc exe gives feedback,
what
it currently defaults to?
in the case of the multiple RTL situation, the target designation gets
enhanced with the encoding (or
In our previous episode, michael.vancann...@wisa.be said:
> > 2. Try a blanket {$H} to make the default stringtype what you want, and fix
> > problems (e.g. overrides of methods, passing to var params).
>
> The blanket {$H} seems like the way to go for most packages.
> If we insert {$H ANSISTRIN
In our previous episode, Sven Barth said:
> > The difference is more that I don't think it will solve as much as people
> > think, and using this to stitch together code from different origins will
> > fail miserably or be unworkable.
>
> For non-inheritance-related code that is encoding-agnostic
On Thu, Oct 13, 2011 at 11:54 AM, Sven Barth
wrote:
> Out of curiosity: how did you come to that conclusion? According to what I
> read in rtl/inc/systemh.inc "PChar" is still defined as an "^Char" and
> further down is also an alias "AnsiChar = Char", so "PChar" should still be
> and behave the s
In our previous episode, Felipe Monteiro de Carvalho said:
> > Out of curiosity: how did you come to that conclusion? According to what I
> > read in rtl/inc/systemh.inc "PChar" is still defined as an "^Char" and
> > further down is also an alias "AnsiChar = Char", so "PChar" should still be
> > an
On Thu, 13 Oct 2011, Marco van de Voort wrote:
In our previous episode, michael.vancann...@wisa.be said:
2. Try a blanket {$H} to make the default stringtype what you want, and fix
problems (e.g. overrides of methods, passing to var params).
The blanket {$H} seems like the way to go for m
In our previous episode, michael.vancann...@wisa.be said:
> > The more procedural packages yes. The OOP ones not, since their stringtype
> > must match classes for overrides.
>
> Yes, but
> 1. this is the smallest group, so I don't consider that a problem.
Only in number of packages.
> 2. I dou
On 13/10/2011 04:55, Michael Schnell wrote:
On 10/13/2011 02:05 AM, Hans-Peter Diettrich wrote:
There is no "Raw" source ID.
The Delphi doc says "the RawByteString Type is type ANSIString($)".
So the RawByte encoding ID in fact is $ (if FPC wants to be Delphi
compatible in that behal
On Thursday 13 October 2011 13.41:24 Marco van de Voort wrote:
> > It's time to cut the gordian knot and take a decision.
> > All pros and contras have been discussed at great length meanwhile.
>
> Exactly. That's why a decision that is futureproof should be made, and not
> just start hacking, an
In our previous episode, Martin Schreiber said:
> Suggestion: Let it be as it is in fixes_2_6, add support for Unicode
> resource strings and invest power into development of Delphi like packages
> for example.
That is already not an option anymore, with the newstr branch merged in.
And while th
On 10/13/2011 02:16 AM, Hans-Peter Diettrich wrote:
Almost every required conversion can be determined at compile time.
The only uncertain case is a result (or other source) of type
RawByteString.
What should be the point in doing a library supporting Strings with
dynamically (at run-time)
Ok, so after summing in all of this problems which we are facing, I
will withdraw all of my previous ideas and agree with you Marco. If
FPC can produce a RTL mode where string=utf8string then I agree
Lazarus should try to use this UTF-8 RTL.
--
Felipe Monteiro de Carvalho
On 10/13/2011 01:45 PM, Luiz Americo Pereira Camara wrote:
This means that StringCodePage is only meaningful when calling it on a
string variable that actually holds a string.
How can a string variable not hold a string ? It might hold an empty
string, but what is a "no-string" ?
Of course
On Thursday 13 October 2011 13.56:50 Marco van de Voort wrote:
> In our previous episode, Martin Schreiber said:
> > Suggestion: Let it be as it is in fixes_2_6, add support for Unicode
> > resource strings and invest power into development of Delphi like
> > packages for example.
>
Or improved op
After the test program, sent by Paul, I was playing more with
AnsiStrings in Delphi XE, with catastrophic results :-(
At least when MBCS enter the scene, and UTF-8 is widely used in FPC and
Lazarus and is the preferred string type on Linux, incredible bugs show
up. With
var
a: AnsiString;
Michael Schnell schrieb:
On 10/13/2011 10:52 AM, Sven Barth wrote:
So you suggest that in Delphi XE, UnicodeString is _not_ a "new String"
Type ?
I don't know what you describe as "new string", but "UnicodeString"
was introduced as a new type in Delphi 2009 and "String" was made an
alias
On 10/13/2011 02:08 PM, Hans-Peter Diettrich wrote:
but you cannot derive further types with different encoding from it,
as you can do from AnsiString.
I see. So these variables don't have a TAnsiRec handling record.
Thanks,
-Michael
___
fpc-devel ma
Am 13.10.2011 14:35, schrieb Michael Schnell:
On 10/13/2011 02:08 PM, Hans-Peter Diettrich wrote:
but you cannot derive further types with different encoding from it,
as you can do from AnsiString.
I see. So these variables don't have a TAnsiRec handling record.
No, they have something else l
In our previous episode, Martin Schreiber said:
> > And while that is an option for you, it doesn't satisfy anybody else. Not
> > even the ones that want as close to D2009 compatibility as possible, since
> > they also need the new ansistring type here and there.
> >
> Hm, even Embarcadero can liv
On 10/13/2011 02:31 PM, Sven Barth wrote:
No, they have something else like TUnicodeRec or so.
Which does not provide a CodePage element ???
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listi
In our previous episode, Michael Schnell said:
> >
> > No, they have something else like TUnicodeRec or so.
> >
> Which does not provide a CodePage element ???
Afaik tansirec (d2009 style)=tunicoderec (d2009) style.
The rawbytestring type afaik depends on that, that any string can be passed
to it
13.10.2011 16:31, Sven Barth пишет:
Am 13.10.2011 14:35, schrieb Michael Schnell:
On 10/13/2011 02:08 PM, Hans-Peter Diettrich wrote:
but you cannot derive further types with different encoding from it,
as you can do from AnsiString.
I see. So these variables don't have a TAnsiRec handling rec
On 10/13/2011 02:36 PM, Marco van de Voort wrote:
Afaik tansirec (d2009 style)=tunicoderec (d2009) style.
The rawbytestring type afaik depends on that,
According to Embarcadero: "RawByteString type is type ANSIString($)"
So the implemented structure of RawByteString and ANSIString obvious
13.10.2011 16:30, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 10:26 AM, Paul Ishenin wrote:
It will affect as well as compiler directive you suggested to add.
No, the directive is per source code file. 3rd party libraries do not
need to use it.
Then use {$codepage UTF8} only. Th
On 13 Oct 2011, at 15:02, Paul Ishenin wrote:
Then use {$codepage UTF8} only. This directive treats all ansistring
constants in UTF8 codepage. So the next code:
{$codepage UTF8}
var
s: ansistring;
begin
s := 'utf8 string';
WriteLn(StringCodePage(s));
end.
will output CP_UTF8 constant.
T
> ... the constant be converted at run
> time from UTF-8 to the DefaultSystemCodePage to make sure that an
> ansistring(0) variable always contains strings encoded in the
> DefaultSystemCodePage? If you assign e.g. a string(866) variable to a plain
> ansistring variable, then such a conversion is a
Sven Barth schrieb:
Am 13.10.2011 14:35, schrieb Michael Schnell:
On 10/13/2011 02:08 PM, Hans-Peter Diettrich wrote:
but you cannot derive further types with different encoding from it,
as you can do from AnsiString.
I see. So these variables don't have a TAnsiRec handling record.
No, they
Jonas Maebe schrieb:
On 13 Oct 2011, at 15:02, Paul Ishenin wrote:
Then use {$codepage UTF8} only. This directive treats all ansistring
constants in UTF8 codepage. So the next code:
{$codepage UTF8}
var
s: ansistring;
begin
s := 'utf8 string';
WriteLn(StringCodePage(s));
end.
will output
On 10/13/2011 4:36 AM, Marco van de Voort wrote:
Plus, isn't Embarcadero pushing FireMonkey anyway?
I don't see it that way. I see FM as a Delphi PHP/3rd Rail/Prism like
product, not as serious VCL contender. If I understood it correctly, it is
mostly a sideproduct of internal efforts to port E
1 - 100 of 105 matches
Mail list logo
