On Wed, Feb 16, 2011 at 09:15:44AM +0200, Graeme Geldenhuys wrote:
> > of such an target-specific string type?
>
> Please do share your thoughts...
>
> I must add, that I would be very surprised if Embarcadero doesn't use
> native encoded string types for the "unicode string" support in the
> upc
Op 2011-02-24 12:36, Felipe Monteiro de Carvalho het geskryf:
>
> Indeed, I hadn't thought about that. That makes the case for a general
> migration to the new string type stronger.
Correct. The generic String type will have a slightly new
meaning/functionality in the future.
> And if we are go
On Wed, Feb 23, 2011 at 3:17 PM, Marco van de Voort wrote:
> FPC RTL/FCL contains classes too. It is not just a few isolated procedures,
> but a lot of classes too. And not all are solvable with overloading.
Indeed, I hadn't thought about that. That makes the case for a general
migration to the n
On Thu, Feb 17, 2011 at 10:20:38AM +0100, Felipe Monteiro de Carvalho wrote:
> On Wed, Feb 16, 2011 at 10:11 PM, Marco van de Voort wrote:
> > How do you duplicate every usage of "string" in the entire Lazarus tree?
>
> I don't understand your question. I proposed to duplicate RTL string
> routin
On 02/22/2011 04:32 PM, Hans-Peter Diettrich wrote:
Generic types should never evolve in a breaking way.
The generic type String once was intended to hold entities of the
generic type char (=character), and char was meant to hold a complete
(maybe) printable thingy in an 8 bit encoding.
So t
Jürgen Hestermann schrieb:
> If I just want a counter, I will just use "integer").
I always use LongInt because when using integer I am not sure what range of
numbers I will get. Who knows what special command line or compiler
switche changes this to 16 bit or even less. Then my program would
Jürgen Hestermann schrieb:
Hans-Peter Diettrich schrieb:
> Generic types should never evolve in a breaking way.
But that's the whole reason for generic types: They should
not map to a specific type but vary dependend on certain
environment settings.
Generic types IMO should vary according to
Hans-Peter Diettrich schrieb:
> Generic types should never evolve in a breaking way.
But that's the whole reason for generic types: They should
not map to a specific type but vary dependend on certain
environment settings. If the generic type String means
the same type all the time than it's just
John schrieb:
> Probably because that was the "normal" way of doing it,
> since ansi/long string was added to Dephi a *long* time ago.
Well, an even longer time ago the type "String" was a ShortString of max
255 characters.
My first contact with the "modern" (generic) meaning of "String" cause
John schrieb:
I suppose if the ansistring type remains, I can do a global replace on
ALL my code, or redeclare string as ansistring, or something, but I
don't see why there should not be a compiler switch to do it, seeing
that that was the way the last string divergence was handled.
String h
Graeme Geldenhuys schrieb:
String is a generic type (it already has multiple meanings), so it
should evolve.
Generic types should never evolve in a breaking way.
Look how even the FPC developers have banned the use of AnsiString, for
performance reasons. [What raises the next question: what
Jürgen Hestermann schrieb:
But why are you using the generic "string" type at all? If you want to
make sure that you use AnsiString or ShortString or whatever then use it
directly. That way you have full control about the string type used.
The compiler should support string types as *really*
Op 2011-02-22 12:08, John het geskryf:
> string was added to Dephi a *long* time ago. Also simply less typing,
> more readable if I always know that a string is just a string.
There is no such thing as "just a string" or "plain text". All text have
some encoding defined/associated to them. ;-)
On 22/02/2011 5:11 PM, Jürgen Hestermann wrote:
> I don't need Unicode support, and I DON'T want to have to worry
about its complexities. > Just leave a compiler mode or switch that
lets me keep "string" as LongString and I will be
> happy, whatever happens with unicode. And, as far as I unders
Op 2011-02-22 11:28, Florian Klaempfl het geskryf:
>
> I'am glad to hear that you're always happy about FPC :)
:-)
>> Out of curiosity, why does ObjFPC mode default to ShortString and not
>> AnsiString?
>
> Why break existing code for nothing?
Supporting legacy code (10-20 years old) with de
Am 22.02.2011 09:58, schrieb Graeme Geldenhuys:
> Op 2011-02-22 10:44, Florian Klaempfl het geskryf:
>> Delphi clone/non delphi clone? Does it ring bells? You always tell us:
>> don't do a delphi clone. Then we don't do it and you cry.
>
> Well make up your bloody mind??? If you want to make FPC a
Op 2011-02-22 10:44, Florian Klaempfl het geskryf:
> Delphi clone/non delphi clone? Does it ring bells? You always tell us:
> don't do a delphi clone. Then we don't do it and you cry.
Well make up your bloody mind??? If you want to make FPC a Delphi clone,
then stick to it. Having some areas clone
Am 22.02.2011 08:58, schrieb Graeme Geldenhuys:
> Op 2011-02-21 10:02, Florian Klaempfl het geskryf:
>>
>> the different handling of temp. interfaces in
>> FPC which is only a implementation detail?
>
> Sorry, no idea how that relates to this discussion.
Delphi clone/non delphi clone? Does
On 02/22/2011 07:11 AM, Jürgen Hestermann wrote:
> If you want to make sure that you use AnsiString...
Oooops, AnsiString and UTF8String are just aliases for the same type.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
Op 2011-02-22 08:11, Jürgen Hestermann het geskryf:
>
> But why are you using the generic "string" type at all? If you want to
> make sure that you use AnsiString or ShortString or whatever then use it
> directly. That way you have full control about the string type used.
Exactly. Just like any o
Op 2011-02-21 10:02, Florian Klaempfl het geskryf:
>
> the different handling of temp. interfaces in
> FPC which is only a implementation detail?
Sorry, no idea how that relates to this discussion. Also, please drop
the childish remarks. Grow up and act your age!
> When did String change f
> I don't need Unicode support, and I DON'T want to have to worry about
its complexities.
> Just leave a compiler mode or switch that lets me keep "string" as
LongString and I will be
> happy, whatever happens with unicode. And, as far as I understand,
you can still set
> string = shortstring
On 21/02/2011 6:09 PM, Graeme Geldenhuys wrote:
Introducing yet another compiler mode also doesn't seem like the way to
go. FPC is already complex enough. The String type simply needs to
evolve to Unicode support, just like it did from ShortString to
LongString. A natural evolution. This should p
On 21.02.2011 09:02, Florian Klaempfl wrote:
Am 21.02.2011 08:09, schrieb Graeme Geldenhuys:
Introducing yet another compiler mode also doesn't seem like the way to
go. FPC is already complex enough. The String type simply needs to
evolve to Unicode support, just like it did from ShortString to
Florian Klaempfl schrieb:
ObjFPC used AnsiString for a String from the beginning ...
You mean ShortString, right?
http://www.freepascal.org/docs-html/prog/progse75.html#x274-289000D.4
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.o
Am 21.02.2011 08:09, schrieb Graeme Geldenhuys:
>
> Introducing yet another compiler mode also doesn't seem like the way to
> go. FPC is already complex enough. The String type simply needs to
> evolve to Unicode support, just like it did from ShortString to
> LongString. A natural evolution.
Re
Op 2011-02-19 13:50, Sven Barth het geskryf:
>
> When you're still working on that branch (you got it to compile again?)
> it might indeed be that you fullfill Florian's point of "those who
> implement it decide how it's done" (more or less).
I've come to realize that discussing a design is fruit
On 2/19/2011 07:25, Hans-Peter Diettrich wrote:
waldo kitty schrieb:
"we don't want/need no mime mess... give us the trademark symbol as '(tm)' and
the copyright symbol as '(c)' and we're just fine."
This can be accomplished in every encoding, by StringReplace.
this is, actually, what i'm d
waldo kitty schrieb:
"we don't want/need no mime mess... give us the trademark symbol as
'(tm)' and the copyright symbol as '(c)' and we're just fine."
This can be accomplished in every encoding, by StringReplace.
DoDi
--
___
Lazarus mailing list
On 18.02.2011 15:57, Graeme Geldenhuys wrote:
Op 2011-02-18 14:19, Hans-Peter Diettrich het geskryf:
Also implied conversions may not be noticeable to many users, and this
also may apply to a future FPC/Lazarus model.
I've lately had a renewed interest in working on the Unicode for FPC, so
hav
On 2/18/2011 11:02, Michael Schnell wrote:
On 02/18/2011 04:12 PM, Hans-Peter Diettrich wrote:
I see no chance for "hard to detect" problems, when some code has been broken
since ever.
I don't feel that the legacy (non-Unicode aware) instruction
MyChar := MyString[Lengt(MyString)];
to get the
On 2/18/2011 10:05, Felipe Monteiro de Carvalho wrote:
On Fri, Feb 18, 2011 at 3:54 PM, Michael Schnell wrote:
Of course not. It should just be renamed to prevent lots of hard to detect
run time problems when used erroneously for "visual character count".
And cause trouble to everyone that h
Graeme Geldenhuys schrieb:
Op 2011-02-18 10:36, Michael Schnell het geskryf:
compiling "old style" software. So I vote for dropping the ambiguously
named "length()" function completely and introduce two new functions
with different names.
+1
+1
--
__
On Thu, Feb 17, 2011 at 08:44:33AM +0200, Graeme Geldenhuys wrote:
> Op 2011-02-16 23:15, Marco van de Voort het geskryf:
> >
> > There is no unicodestring(...). Ansistring(...) and
>
> I know there currently isn't, but are you also saying that we can't
> extend UnicodeString to support UnicodeSt
Michael Schnell schrieb:
On 02/18/2011 04:12 PM, Hans-Peter Diettrich wrote:
I see no chance for "hard to detect" problems, when some code has been
broken since ever.
I don't feel that the legacy (non-Unicode aware) instruction
MyChar := MyString[Lengt(MyString)];
to get the last charac
On 02/18/2011 04:12 PM, Hans-Peter Diettrich wrote:
I see no chance for "hard to detect" problems, when some code has been
broken since ever.
I don't feel that the legacy (non-Unicode aware) instruction
MyChar := MyString[Lengt(MyString)];
to get the last character of a string is broken
Michael Schnell schrieb:
On 02/18/2011 01:24 PM, Hans-Peter Diettrich wrote:
Length() cannot be dropped
Of course not. It should just be renamed to prevent lots of hard to
detect run time problems when used erroneously for "visual character
count".
Then the problem sits before the screen ;
On Fri, Feb 18, 2011 at 3:54 PM, Michael Schnell wrote:
> Of course not. It should just be renamed to prevent lots of hard to detect
> run time problems when used erroneously for "visual character count".
And cause trouble to everyone that has been using it correctly? I
don't think so.
Plus, La
Op 2011-02-18 14:19, Hans-Peter Diettrich het geskryf:
> Also implied conversions may not be noticeable to many users, and this
> also may apply to a future FPC/Lazarus model.
I've lately had a renewed interest in working on the Unicode for FPC, so
have been silently hammering away at the code in
On 02/18/2011 01:24 PM, Hans-Peter Diettrich wrote:
Length() cannot be dropped
Of course not. It should just be renamed to prevent lots of hard to
detect run time problems when used erroneously for "visual character
count".
-Michael
--
___
Lazaru
Juha Manninen schrieb:
Marc Weustink kirjoitti perjantai 18 helmikuu 2011 12:01:45:
Nope, from day 1 of lazarus, Length() returned the number of *physical*
elements. Only in some cases this happened to be the number of *visible*
characters.
We are talking about software here so they are not re
Michael Schnell schrieb:
On 02/17/2011 01:41 PM, Hans-Peter Diettrich wrote:
IMO we simply have to agree that Length() is a physical property,
This would result in many errors with "old style" trained users and when
compiling "old style" software. So I vote for dropping the ambiguously
named "
Graeme Geldenhuys schrieb:
Op 2011-02-17 13:58, Hans-Peter Diettrich het geskryf:
IMO the new Unicode versions broke so much legacy code, that FPC/Lazarus
could become a real successor of the last Ansi version,
I don't think so. Yes the Unicode support in Delphi broke a lot of code,
but I thin
Michael Schnell hat geschrieben:
On 02/18/2011 11:40 AM, Mattias Gaertner wrote:
/
/>/> Otherwise this thread will go endless without a solution.
/> //This is true with any Unicode discussion,
...even more so if you are involved in that discussion
s.c.n.r
:-)
--
___
On 02/18/2011 11:40 AM, Mattias Gaertner wrote:
Otherwise this thread will go endless without a solution.
This is true with any Unicode discussion, as the hope that Unicode "fits
all needs" , and the hope that the conversion of existing software to
Unicode could be rather easy, and the hope
Op 2011-02-18 12:10, Juha Manninen het geskryf:
>
> We are talking about software here so they are not really physical.
> A coffee cup, a fork and a knife are physical elements.
> :-)
In the Sims game they are not. ;-)
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit usi
Michael Schnell hat am 18. Februar 2011 um 11:23
geschrieben:
> On 02/18/2011 11:01 AM, Marc Weustink wrote:
> >
> > Nope, from day 1 of lazarus, Length() returned the number of
> > *physical* elements. Only in some cases this happened to be the number
> > of *visible* characters.
> Of course
On 02/18/2011 11:01 AM, Marc Weustink wrote:
Nope, from day 1 of lazarus, Length() returned the number of
*physical* elements. Only in some cases this happened to be the number
of *visible* characters.
Of course you are right, but inviable characters are no real problem
here, visible characte
Marc Weustink kirjoitti perjantai 18 helmikuu 2011 12:01:45:
> Nope, from day 1 of lazarus, Length() returned the number of *physical*
> elements. Only in some cases this happened to be the number of *visible*
> characters.
We are talking about software here so they are not really physical.
A coff
Michael Schnell wrote:
On 02/17/2011 02:56 PM, Hans-Peter Diettrich wrote:
Length() since ever returned the number of *physical* elements.
Length() since ever returned the number of *visible* characters (until
Unicode was introduced to Lazarus :).
Nope, from day 1 of lazarus, Length() returne
Op 2011-02-18 10:36, Michael Schnell het geskryf:
> compiling "old style" software. So I vote for dropping the ambiguously
> named "length()" function completely and introduce two new functions
> with different names.
+1
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit usi
; KDE/4.5.4;
x86_64; ; )
MIME-Version: 1.0
Message-Id: <20101232.46631.juha.mannine...@gmail.com>
Subject: [Lazarus] Does Lazarus support a complete Unicode Component
Library?
X-BeenThere: lazarus@lists.lazarus.freepascal.org
X-Mailman-Version: 2.1.11
Precedence
x-aol-sid: 3039ac1d33834d5d43572286
Subject: Re: [Lazarus] Does Lazarus
supporta complete Unicode Component Library?
X-BeenThere: lazarus@lists.lazarus.freepascal.org
X-Mailman-Version: 2.1.11
Precedence: list
===
The count spaces that have been co
On 02/17/2011 02:56 PM, Hans-Peter Diettrich wrote:
What's simply nonsense with UTF-8/16 strings :-(
Of course right now it is. But this is what average programmers are used
to and what we will see in tons of legacy code that might one day is
needed top be compiled with a new version of Lazaru
On 02/17/2011 03:02 PM, Hans-Peter Diettrich wrote:
It also may be Michael Schnell, whose mailer inserts the tabs into the
subject.
I use Thunderbird on Linux.
I have no knowledge of something like this happening and in fact I don't
see any quirky subjects in this thread. Where do you see th
On 02/17/2011 01:41 PM, Hans-Peter Diettrich wrote:
IMO we simply have to agree that Length() is a physical property,
This would result in many errors with "old style" trained users and when
compiling "old style" software. So I vote for dropping the ambiguously
named "length()" function complet
On 02/17/2011 12:58 PM, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
The debugging of cross-platform applications requires a separate
target machine anyhow, so that virtualization is almost a *must* for
the new Delphi versions.
Do you actually have a "new cross platform Delphi" ?
-Micha
Op 2011-02-17 13:58, Hans-Peter Diettrich het geskryf:
>
> IMO the new Unicode versions broke so much legacy code, that FPC/Lazarus
> could become a real successor of the last Ansi version,
I don't think so. Yes the Unicode support in Delphi broke a lot of code,
but I think that was just a small
> If so, then I wouldn't waist any more of my time on working on the
> cpstrnew branch
FPC still follows the thumb rule (notice the thumb rule): the person who
implements a certain feature, decides. E.g. if somebody comes up with a
working code paged string implementation without breaking existing
Hans-Peter Diettrich schrieb:
Marco van de Voort schrieb:
Can you please make your mailer preserve *spaces* in the subject?
Sorry, I seem to address the wrong person :-(
It also may be Michael Schnell, whose mailer inserts the tabs into the
subject. It would be nice if everybody would check
Michael Schnell schrieb:
That's why such loops should be disallowed with Unicode strings, as
kind of low level string handling.
Not only this, but the normal user would like to do
MyChar := MyString[Length(MyString];
to get the last character of a string.
What's simply nonsense with UTF-
Graeme Geldenhuys schrieb:
Op 2011-02-17 00:58, Hans-Peter Diettrich het geskryf:
What's the type of the loop variable???
Any time that can store 4-bytes. Be that a string, dynamic array or a
custom object/class type.
String iteration, based on such positions, is quite useless, because
then
Michael Schnell schrieb:
Dealing with *all* the Unicode quirks IMO is beyond "usual" coding, it
will be reserved to specialized text processing components or
applications.
+1 from here,
but I never did anything with Mac and I once was told that the Mac
constantly uses such quirks.
When a Ma
Michael Schnell schrieb:
combining diacritics etc.
This of course does not work, as theses "Unicode quirks" (this name was
not introduced by me !) forces that the same visual character can be
encoded in different ways. I don't know if it is even possible (and
sensible) to support this at lang
Graeme Geldenhuys schrieb:
Op 2011-02-17 11:28, Michael Schnell het geskryf:
On 02/17/2011 07:19 AM, Jürgen Hestermann wrote:
I often search for substrings, delete them from the string, insert
other strings at certain places, etc.
How can you do all this without knowledge of the internal struct
Sven Barth schrieb:
Hans-Peter also raised a valid point. FPC had a goal to be Delphi 7
compatible, so that should leave use open to me inventive and learn from
post-Delphi 7 mistake, and make FPC even better than Delphi 7+. If FPC
just wants to be a Delphi clone, then why use FPC - just switch
Jürgen Hestermann schrieb:
Hans-Peter Diettrich schrieb:
> Indexed access to characters is a low level operation, that should
not be used in Unicode-aware applications without specific knowledge.
I often search for substrings, delete them from the string, insert other
strings at certain plac
On Thu, Feb 17, 2011 at 3:44 AM, Graeme Geldenhuys
wrote:
> I guess the most logical would be String(…) syntax - upgrading the
> String type to be encoding aware, similar to what was done when String
> was a shortstring and then became a longstring later. Making the String
> type encoding-aware wo
Graeme Geldenhuys hat am 17. Februar 2011 um 10:35
geschrieben:
> Op 2011-02-17 11:28, Michael Schnell het geskryf:
> > On 02/17/2011 07:19 AM, Jürgen Hestermann wrote:
> >>
> >> I often search for substrings, delete them from the string, insert
> >> other strings at certain places, etc.
> >
On 02/17/2011 10:35 AM, Graeme Geldenhuys wrote:
You can't use FPC's Copy(), Pos() etc reliably with
UTF-8 text, because thouse RTL functions work purely on ANSI text
(1-byte characters - speaking of String type text here) and don't know
about multi-byte characters,
Thats the "magic" :-) . pos(
On 02/17/2011 12:02 AM, Hans-Peter Diettrich wrote:
That's why such loops should be disallowed with Unicode strings, as
kind of low level string handling.
Not only this, but the normal user would like to do
MyChar := MyString[Length(MyString];
to get the last character of a string.
This
Op 2011-02-17 11:28, Michael Schnell het geskryf:
> On 02/17/2011 07:19 AM, Jürgen Hestermann wrote:
>>
>> I often search for substrings, delete them from the string, insert
>> other strings at certain places, etc.
>> How can you do all this without knowledge of the internal structure of
>> the str
On 02/17/2011 12:08 AM, Hans-Peter Diettrich wrote:
Depends on the type of i. Neither Char nor WideChar are capable of
holding every Unicode codepoint (32 bit).
I think Graeme wrote:
c: UnicodeChar; // or something that can store at least 4 bytes
(meaning i instead of c)
-Michael
--
_
On 02/17/2011 07:19 AM, Jürgen Hestermann wrote:
I often search for substrings, delete them from the string, insert
other strings at certain places, etc.
How can you do all this without knowledge of the internal structure of
the string?
This (magically :-) ) does work with UTF8. You just can't
On 02/16/2011 11:58 PM, Hans-Peter Diettrich wrote:
Dealing with *all* the Unicode quirks IMO is beyond "usual" coding, it
will be reserved to specialized text processing components or
applications.
+1 from here,
but I never did anything with Mac and I once was told that the Mac
constantly u
On Wed, Feb 16, 2011 at 10:11 PM, Marco van de Voort wrote:
> How do you duplicate every usage of "string" in the entire Lazarus tree?
I don't understand your question. I proposed to duplicate RTL string
routines. Lazarus would use only the UTF-8 variant and thus Lazarus
routines don't need to be
Hello Lazarus-List,
Thursday, February 17, 2011, 8:21:07 AM, you wrote:
GG> Well, for any string handling in your application, you need to know the
GG> difference between what is perceived as a Unicode "character" on the
GG> screen, and the various ways such a "character" can be presented in a
GG
[OT]
Am 17.02.2011 08:21, schrieb Graeme Geldenhuys:
Maybe some day you
want to translate all your text into Klingon or Goa'uld or whatever
alien race visits our planet. Being prepared and supporting the full
Unicode is the best option at the moment.
If I wouldn't be at work know, I would have
Am 17.02.2011 07:54, schrieb Graeme Geldenhuys:
I'm afraid that due to this "compatibility" we're doomed to clone the
Delphi implementation whatever crappy it is :(
If so, then I wouldn't waist any more of my time on working on the
cpstrnew branch (which I have been doing quietly on my own). If
Op 2011-02-17 00:58, Hans-Peter Diettrich het geskryf:
>
> What's the type of the loop variable???
Any time that can store 4-bytes. Be that a string, dynamic array or a
custom object/class type.
> The iteration costs time, so that many users will insist in using "fast"
> SBCS access.
That woul
Op 2011-02-16 20:25, Sergei Gorelkin het geskryf:
> In Delphi, UnicodeString is a very separate type, something close to the
> current FPC design.
> It has BytesPerChar and Encoding attributes, but they are fixed to 2 and
> 1200 respectively and their purpose is unclear (to consume memory?
Now tha
Op 2011-02-16 23:15, Marco van de Voort het geskryf:
>
> There is no unicodestring(...). Ansistring(...) and
I know there currently isn't, but are you also saying that we can't
extend UnicodeString to support UnicodeString(…) syntax? To me,
AnsiString(…) [like is done in Delphi now], makes even l
Hans-Peter Diettrich schrieb:
> Indexed access to characters is a low level operation, that should
not be used in Unicode-aware applications without specific knowledge.
I often search for substrings, delete them from the string, insert other
strings at certain places, etc.
How can you do all t
Michael Schnell schrieb:
Delphi Prism would go
for each i in itrdo
begin
... now do something with the Unicode character stored in i
end;
Depends on the type of i. Neither Char nor WideChar are capable of
holding every Unicode codepoint (32 bit).
DoDi
--
__
Marco van de Voort schrieb:
Can you please make your mailer preserve *spaces* in the subject?
DoDi
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Michael Schnell schrieb:
I'm pretty sure that such strings will be widely used, by people that
prefer to use string indexing with a fixed character size.
Yep. Bus as discussed here earlier, Length() - that needs to be done
with the same paradigm as mystr[i] - is a problem. When using e.g.
stre
Graeme Geldenhuys schrieb:
Op 2011-02-16 12:52, Hans-Peter Diettrich het geskryf:
Most people have been sure, in the past, that they use a SBCS, where
every character on screen is a char in memory. And consequently they use
indexed access to the chars in an string, and for...to loops.
Yes, and
Sergei Gorelkin schrieb:
I'm afraid that due to this "compatibility" we're doomed to clone the
Delphi implementation whatever crappy it is :(
I'm not sure whether we have to be compatible with Delphi>7, and whether
the Delphi Unicode implementation is crappy. At least the choosen
implementat
Sven Barth schrieb:
The following compiles:
type
UTF8String = type AnsiString(65001);
but the following does not:
type
UTF8String = type UnicodeString(65001); // ';' expected, but '(' found
Tested using Delphi XE (65001 is the codepage for UTF-8 on Windows).
Please test again, with som
On Mon, Feb 14, 2011 at 03:35:32PM +0200, Graeme Geldenhuys wrote:
> "alias types" are not really new types, so will not affect var
> parameters. So in my previous example, UTF16String will still be a
> UnicodeString. The only difference will be that UTF16String has its
> internal encoding bit se
On Mon, Feb 14, 2011 at 11:07:51AM +0100, Michael Schnell wrote:
> On 02/12/2011 06:49 PM, Marco van de Voort wrote:And currently
> UTF8String is defined as AnsiString, so there is currently no
> >>> difference
> >> That's what I thought. So why did they [FPC team] actually bother to
> >> create t
On Mon, Feb 14, 2011 at 12:16:55PM +0100, Felipe Monteiro de Carvalho wrote:
> On Sat, Feb 12, 2011 at 6:49 PM, Marco van de Voort wrote:
> > This is all undecided. I lean towards splitting operating system targets
> > into a utf8 and a utf16 one for most platforms(*), since nobody will ever
> >
Sven Barth пишет:
Am 16.02.2011 11:52, schrieb Hans-Peter Diettrich:
I must add, that I would be very surprised if Embarcadero doesn't use
native encoded string types for the "unicode string" support in the
upcoming Delphi under Windows (UTF-16), Linux (UTF-8), Mac (UTF-8) etc..
I'm not 100% sur
On 02/16/2011 03:04 PM, Sven Barth wrote:
It's the Delphi compatible variant of the Prism syntax.
Sounds great.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Op 2011-02-16 15:59, Michael Schnell het geskryf:
> Do we already have / plan a dedicated iterator loop syntax for this
A similar syntax is already supported in FPC 2.4.2. See the Language
Reference documentation, section 10.2.5 (pg 115 in the ref.pdf).
I personally prefer the Iterator interface
Am 16.02.2011 14:59, schrieb Michael Schnell:
On 02/16/2011 01:59 PM, Graeme Geldenhuys wrote:
while itr.HasNext do
begin
i := itr.Next
... now do something with the Unicode character stored in i
end;
Do we already have / plan a dedicated iterator loop syntax for this
Delphi Prism would go
f
On 02/16/2011 01:59 PM, Graeme Geldenhuys wrote:
while itr.HasNext do
begin
i := itr.Next
... now do something with the Unicode character stored in i
end;
Do we already have / plan a dedicated iterator loop syntax for this
Delphi Prism would go
for each i in itrdo
begin
Op 2011-02-16 14:25, Michael Schnell het geskryf:
> Yep. Bus as discussed here earlier, Length() - that needs to be done
> with the same paradigm as mystr[i] - is a problem. When using e.g.
> stream-I/O people will want it to be the byte count, when doing a loop
> along a string, they want it to be
Op 2011-02-16 12:52, Hans-Peter Diettrich het geskryf:
> Most people have been sure, in the past, that they use a SBCS, where
> every character on screen is a char in memory. And consequently they use
> indexed access to the chars in an string, and for...to loops.
Yes, and that code accesses strin
On 02/16/2011 12:04 PM, Hans-Peter Diettrich wrote:
I'm pretty sure that such strings will be widely used, by people that
prefer to use string indexing with a fixed character size.
Yep. Bus as discussed here earlier, Length() - that needs to be done
with the same paradigm as mystr[i] - is a pr
1 - 100 of 164 matches
Mail list logo
