In our previous episode, Felipe Monteiro de Carvalho said:
On Mon, Dec 1, 2008 at 7:33 PM, Martin Friebe [EMAIL PROTECTED] wrote:
I suggested to have a rtl, that has overloaded functions for each string
type.
of course that sounds easier than in fact it will be.
This is about the same as
I never suggested the RTL to be in a fixed encoding. I fully agree
that this would be far worse.
I suppose there are (quite decently workable) solutions for this. Either
the RTL (and LCL, FWIW) comes in multiple versions that are used as
appropriate (user selectable and/or automatically
This is about the same as having all string routines in 3 flavours:
RTLString, utf-8 and utf-16
What about (real) ANSIString (OS/locale based coded) ? This needs to be
allowed as the program might need to read such files.
-Michael
___
fpc-devel
Felipe Monteiro de Carvalho schrieb:
On Mon, Dec 1, 2008 at 8:27 PM, Mattias Gaertner
[EMAIL PROTECTED] wrote:
I don't see, how a TLCLStrings will *not* break Delphi and Lazarus
compatibility. Maybe you can give some more details, how it should work.
It was just a initial idea. I now see
For me, these attempts to make compiler do everything automatically sound
like getting yet another typing saver.
Maybe I am just being lazy, but it's not a typing saver but regarding
the previous not-Unicode aware versions it's more a preventer of a
typing enhancer :) .
OTOH it's not just
I now understand that GB2312 and JIS 0213 in fact are the ANSI code
pages 936 and 932.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Tue, Dec 2, 2008 at 8:57 AM, Alexander Klenin [EMAIL PROTECTED] wrote:
But Pascal still had the advantage in contests despite RTL weakness.
I believe this comes primarily from the fact that simpler and cleaner
syntax of Pascal
leads to fewer mistakes, and the cost of mistake is very high at
Zitat von Michael Schnell [EMAIL PROTECTED]:
For me, these attempts to make compiler do everything automatically sound
like getting yet another typing saver.
Maybe I am just being lazy, but it's not a typing saver but regarding
the previous not-Unicode aware versions it's more a preventer
On Tue, Dec 2, 2008 at 21:04, Felipe Monteiro de Carvalho
[EMAIL PROTECTED] wrote:
What does STL offer that the FPC RTL/FCL doesn't?
Primarily a well-developed collection of algorithms and data structures
suitable for natural and efficient integration into application programs.
The last part is
IMHO it has been already discussed too often.
I did not start it and only 1% of the contributions are mine - and yours
-, so quite obviously there is a decent common wish for a solution of
what is percept as a problem.
-Michael
___
fpc-devel
Alexander Klenin schrieb:
partially implemented, so I believe current functionality is not enough yet
to create anything competitive with the STL.
Did you ever try to debug STL based programs even with a in this regard
good debugger?
___
fpc-devel
avoids automatic
conversion between types as much as possible.
I feel that it's a goody of a strongly typed language that automatic
type conversions can be done by creating the appropriate code statically
instead of having this embedded in the objects as with variants.
If doing a simple
In our previous episode, Graeme Geldenhuys said:
Why reinvent the wheel with all these different string types and
round-about discussions etc... Can we learn something from other
multi-platform frameworks that solved these problems ages ago!
Who said they did? Who says their solution is more
Graeme Geldenhuys wrote:
So would it maybe help if we took a peek at what those frameworks have
done. Clearly they managed to do it right as no developers or users
are complaining! So I guess Free Pascal could learn from them and
don't have to go through the whole RD process. Study what those
The type is called ansistring simply for backwards compatibility.
You could start arguing that everything should be intuitive. Take C
for example. What does the operator tell you about what it does?
Shouldn't it have a intuitive form? But in the end this is how the
language is and this is a
On Tue, Dec 2, 2008 at 10:47 AM, Sergei Gorelkin
[EMAIL PROTECTED] wrote:
Third, QT is a shared library (and Java framework may also be treated as
such), and it implements huge Unicode conversion tables without putting them
into every executable.
Not every executable. Only if you want to use
On Tue, Dec 2, 2008 at 2:47 PM, Sergei Gorelkin [EMAIL PROTECTED] wrote:
Unfortunately what those frameworks did isn't directly applicable to FPC.
First, as I understand, they have only one (UTF-16) string type. This is
good because it avoids whatever mess related to conversions, but not an
Graeme Geldenhuys wrote:
Then for backward compatibility use UTF-8 as the only string type.
That's what UTF-8 was designed for - backward compatibility. That's
also the reason LCL uses UTF-8.
You cannot use *only* utf-8, the existing ShortString, AnsiString and
Wide/UnicodeString types have
On Tue, Dec 2, 2008 at 2:31 PM, Marco van de Voort [EMAIL PROTECTED] wrote:
Why reinvent the wheel with all these different string types and
round-about discussions etc... Can we learn something from other
multi-platform frameworks that solved these problems ages ago!
Who said they did?
In our previous episode, Sergei Gorelkin said:
don't have to go through the whole RD process. Study what those two
frameworks did and apply the same thing to Free Pascal!
Unfortunately what those frameworks did isn't directly applicable to FPC.
First, as I understand, they have only one
Don't forget that the ansistring type is actually multiple encodings and
even multi byte (even not considering UTF-8). The point is: nobody took
care of it.
IMHO a major confusion is generated by calling a string that is supposed
to hold UTF8 data ANSIString. This never should have happened
Mattias Gärtner schrieb:
Zitat von Florian Klaempfl [EMAIL PROTECTED]:
Mattias Gaertner schrieb:
You can optimize for one encoding or optimize for one per platform. I
know how to optimize for widestrings, for ansistring and for UTF-8
strings, but I have no experience in optimizing for
I meant more that a lot of people simply ignored in their code that
ansistrings could be also multibyte even not considering UTF-8.
Ignoring that ANSI Characters $7F are locale depending makes a program
work perfectly in a single country and mostly decently in many others.
Ignoring that
Op Tue, 2 Dec 2008, schreef Michael Schnell:
Nobody talks in this case about UTF-8. Even *ANSIstrings* in there
native meaning can contain multi byte chars, there are *multi byte* ansi
char sets.
If there is a widely used multi-byte ANSI encoding, why so we need Unicode ?
IMHO the
Michael Schnell schrieb:
Don't forget that the ansistring type is actually multiple encodings and
even multi byte (even not considering UTF-8). The point is: nobody took
care of it.
IMHO a major confusion is generated by calling a string that is supposed
to hold UTF8 data ANSIString.
In our previous episode, Graeme Geldenhuys said:
Why reinvent the wheel with all these different string types and
round-about discussions etc... Can we learn something from other
multi-platform frameworks that solved these problems ages ago!
Who said they did?
Well, who said they
On Tue, Dec 2, 2008 at 22:15, Florian Klaempfl [EMAIL PROTECTED] wrote:
Alexander Klenin schrieb:
partially implemented, so I believe current functionality is not enough yet
to create anything competitive with the STL.
Did you ever try to debug STL based programs even with a in this regard
So, really? What is not supported?
If just ignoring the fact is enough support, OK, it's supported :).
... tell this 1+ Billion (Billion=10^9 in this case) people in China.
I did not know (or suppose) that code used for Chinese characters is
called ANSI (American National Standards
Michael Schnell wrote:
The more I think about it the more I like this solution. I think it's
better then the previous idea of a string with encode information
inside it.
Would Lazarus be able to follow ?
Do you think it's possible to have the compiler take care of any
necessary
On Tue, Dec 2, 2008 at 4:01 PM, Marco van de Voort [EMAIL PROTECTED] wrote:
I can only guess about QT's reasons. In Kylix times I once heard a rumour
that QT was mostly modeled after NT's api philosophy, to make it programmers
easier to migrate.
I have never heard that and can't think that's
Michael Schnell schrieb:
Nobody talks in this case about UTF-8. Even *ANSIstrings* in there
native meaning can contain multi byte chars, there are *multi byte* ansi
char sets.
If there is a widely used multi-byte ANSI encoding, why so we need
Unicode ?
IMHO the introduction of Unicode
On 02 Dec 2008, at 03:11, Sooky Boo wrote:
In c++ the register keyword tries to make the compiler use the CPU's
registers if possible for the variable being defined.
The register keyword is completely ignored by pretty much any modern
C(++) compiler out there.
Jonas
On Tue, December 2, 2008 13:59, Graeme Geldenhuys wrote:
On Tue, Dec 2, 2008 at 2:47 PM, Sergei Gorelkin [EMAIL PROTECTED]
wrote:
Unfortunately what those frameworks did isn't directly applicable to
FPC.
First, as I understand, they have only one (UTF-16) string type. This is
good because
Felipe Monteiro de Carvalho wrote:
Ignore the name ansi. Take it as a string type with the system
encoding. I think it will solve the confusion.
Of course if you ignore ANSI and just use the type named String
there is no confusion as it's clear that the coding is not predefined.
That is
Michael Schnell schrieb:
I meant more that a lot of people simply ignored in their code that
ansistrings could be also multibyte even not considering UTF-8.
Ignoring that ANSI Characters $7F are locale depending makes a program
work perfectly in a single country and mostly decently in
The point is: if everybody takes care of the fact that ansistrings can
be multibyte, having utf-8 in ansistrings (if it's the locale encoding),
is no big deal at all.
I do understand. But (in a real world) do you know anybody who does.
If it would be appropriate for ANSI code handling to
Mattias Gaertner schrieb:
You can optimize for one encoding or optimize for one per platform. I
know how to optimize for widestrings, for ansistring and for UTF-8
strings, but I have no experience in optimizing for multiple
encodings.
Don't forget that the ansistring type is actually
Alexander Klenin schrieb:
On Tue, Dec 2, 2008 at 22:15, Florian Klaempfl [EMAIL PROTECTED] wrote:
Alexander Klenin schrieb:
partially implemented, so I believe current functionality is not enough yet
to create anything competitive with the STL.
Did you ever try to debug STL based programs
Michael Schnell schrieb:
So, really? What is not supported?
If just ignoring the fact is enough support, OK, it's supported :).
What FUD is this? Pleaes give an example where the FPC compiler doesn't
handle multi byte ansistrings properly.
Or do you just want to troll around? This
Florian Klaempfl schrieb:
Alexander Klenin schrieb:
On Tue, Dec 2, 2008 at 22:15, Florian Klaempfl [EMAIL PROTECTED] wrote:
Alexander Klenin schrieb:
partially implemented, so I believe current functionality is not enough yet
to create anything competitive with the STL.
Did you ever try to
Zitat von Florian Klaempfl [EMAIL PROTECTED]:
Mattias Gaertner schrieb:
You can optimize for one encoding or optimize for one per platform. I
know how to optimize for widestrings, for ansistring and for UTF-8
strings, but I have no experience in optimizing for multiple
encodings.
Don't
Nobody talks in this case about UTF-8. Even *ANSIstrings* in there
native meaning can contain multi byte chars, there are *multi byte* ansi
char sets.
If there is a widely used multi-byte ANSI encoding, why so we need
Unicode ?
IMHO the introduction of Unicode has been necessary as (like
If just ignoring the fact is enough support, OK, it's supported :).
What FUD is this? Pleaes give an example where the FPC compiler doesn't
handle multi byte ansistrings properly.
Sorry for bad language :( ! I did not mean to be aggressive. (Did you
see the smile indicator ?)
I
It simply needs no explicit support except what it has already. Mainly
the rtl and the user program has to take care of it and we did this
already in the rtl but the compiler required no fix in this regard so far.
I do see your point !
But my point is that with the introduction of Unicode,
Thanks
On Tue, Dec 2, 2008 at 8:07 AM, Jonas Maebe [EMAIL PROTECTED]wrote:
On 02 Dec 2008, at 03:11, Sooky Boo wrote:
In c++ the register keyword tries to make the compiler use the CPU's
registers if possible for the variable being defined.
The register keyword is completely ignored by
Michael Schnell schrieb:
If just ignoring the fact is enough support, OK, it's supported :).
What FUD is this? Pleaes give an example where the FPC compiler doesn't
handle multi byte ansistrings properly.
Sorry for bad language :( ! I did not mean to be aggressive. (Did you
see
Op Tue, 2 Dec 2008, schreef Michael Schnell:
Thanks for pointing this out.
GB2312 suits them well. Likewise, JIS 0213 suits the Japanese well.
Are these called ANSI ?
Yes, code page 936 and code page 932 are valid ANSI code pages.
These standards by themselves of course not, because
Michael Schnell schrieb:
Felipe Monteiro de Carvalho wrote:
Ignore the name ansi. Take it as a string type with the system
encoding. I think it will solve the confusion.
Of course if you ignore ANSI and just use the type named String
there is no confusion as it's clear that the coding is
Btw will the LCL remain forcedly UTF-8 ? I thought the current Lazarus
unicode support was temporary and all options were still open, depending on
the outcome of FPC unicode support options?
I understand they could not do it differently (other than just providing
no Unicode support at all),
Op Tue, 2 Dec 2008, schreef Michael Schnell:
I supposed one of the main intentions for the move to Unicode was the ability
to support Chinese above all. So they did not seem to have been content with
what was done before.
Is anybody from China here to offer the footage ?
It is not the
On Tue, Dec 2, 2008 at 9:00 AM, Michael Schnell [EMAIL PROTECTED] wrote:
I still don't understand what ANSI has to do with System.
Ignore the name ansi. Take it as a string type with the system
encoding. I think it will solve the confusion.
--
Felipe Monteiro de Carvalho
The more I think about it the more I like this solution. I think it's
better then the previous idea of a string with encode information
inside it.
Would Lazarus be able to follow ?
Do you think it's possible to have the compiler take care of any
necessary conversions automatically ?
Zitat von Michael Schnell [EMAIL PROTECTED]:
The point is: if everybody takes care of the fact that ansistrings can
be multibyte, having utf-8 in ansistrings (if it's the locale encoding),
is no big deal at all.
I do understand. But (in a real world) do you know anybody who does.
If
Thanks for pointing this out.
GB2312 suits them well. Likewise, JIS 0213 suits the Japanese well.
Are these called ANSI ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Michael Schnell schrieb:
Thanks for pointing this out.
GB2312 suits them well. Likewise, JIS 0213 suits the Japanese well.
Are these called ANSI ?
Every well educated windows programmer knows that the ansi
functions/strings whatever are not limited to the so-called ansi code
pages (which
UTF-8 is unicode and it is the system encoding on linux, OS X, some BSDs and
Solaris. So ansistrings are UTF-8 there.
I still don't understand what ANSI has to do with System.
AFAIK, The term ANSI Code stands for a (codepage depending) definition
for a character encoding and Unicode is
Michael Schnell schrieb:
The point is: if everybody takes care of the fact that ansistrings can
be multibyte, having utf-8 in ansistrings (if it's the locale encoding),
is no big deal at all.
I do understand. But (in a real world) do you know anybody who does.
If it would be
Not to mention: What would the alternative be?
Even if I am not satisfied with the current state of Lazarus on that
behalf, I would not dare to suggest that Lazarus should do any change
here before the next version of FPC offers a new string handling with
either a string type that knows
Hello,
I tryed to create a test case based on some previous discussion and
the examples:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revrevision=12290
Why don't the test cases have program ... ?
And what does the numbering mean?
thanks,
--
Felipe Monteiro de Carvalho
Ah, and why is it written that test cases should return 0 but none of
them actually do that? Is it the standard result?
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Op dinsdag 02-12-2008 om 14:03 uur [tijdzone -0200], schreef Felipe
Monteiro de Carvalho:
Hello,
I tryed to create a test case based on some previous discussion and
the examples:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revrevision=12290
Why don't the test cases have program
On Tue, Dec 2, 2008 at 2:22 PM, Joost van der Sluis [EMAIL PROTECTED] wrote:
Why should they? I think that those people writing those tests were
lazy.
well, usually I expect my pascal source to look like a pascal source,
which includes starting with program or unit. I assume that program is
On 02 Dec 2008, at 17:03, Felipe Monteiro de Carvalho wrote:
I tryed to create a test case based on some previous discussion and
the examples:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revrevision=12290
That test should be moved though. Tests in the standard test
directories
Done, except for regenerating the makefile
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Marco van de Voort wrote:
In our previous episode, Mark Morgan Lloyd said:
Looking at 2.2.3 on sparc-linux I see that libc.ppu etc. is no longer
being built, it is however built for i386 and arm and for 2.2.0 and
older. Is this intentional?
To be honest I can't remember why I needed this but
65 matches
Mail list logo
