On 05/11/2016 04:38 PM, Michael Van Canneyt wrote:
Where is the string-type for string-buffers gone?
There never was one, this would break in 2.6.4 too.
Right.
But ->
http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support
-Michael
__
On 2016-05-11 21:58, Mattias Gaertner wrote:
>> > They made the changes to take advantage of the new
>> > functionality in FPC 3.0, because the end result is much simpler code
>> > both in the LCL and in user programs.
>
> Yes, simpler and more powerful. For example FPC now supports full UTF-8
> in
On Wed, 11 May 2016 22:33:13 +0200
Jonas Maebe wrote:
> Graeme Geldenhuys wrote:
> > On 2016-05-11 18:58, Michael Van Canneyt wrote:
> >> > For 99,99% of cases, no changes to your code are required.
> >> > If it worked in 2.6.4, it will work in 3.0.0
> >
> > Just curious, so why was there so ma
On Wed, May 11, 2016 22:08, Graeme Geldenhuys wrote:
> On 2016-05-11 18:58, Michael Van Canneyt wrote:
>> For 99,99% of cases, no changes to your code are required.
>> If it worked in 2.6.4, it will work in 3.0.0
>
> Just curious, so why was there so many changes required for LCL, and a
> whole wik
Graeme Geldenhuys wrote:
On 2016-05-11 18:58, Michael Van Canneyt wrote:
> For 99,99% of cases, no changes to your code are required.
> If it worked in 2.6.4, it will work in 3.0.0
Just curious, so why was there so many changes required for LCL, and a
whole wiki page of its own to explain it
On 2016-05-11 18:58, Michael Van Canneyt wrote:
> For 99,99% of cases, no changes to your code are required.
> If it worked in 2.6.4, it will work in 3.0.0
Just curious, so why was there so many changes required for LCL, and a
whole wiki page of its own to explain it?
Regards,
Graeme
--
fpGU
Am 11.05.2016 19:35 schrieb "Santiago A." :
> Something about codpages needs a second thought.
>
> a) There shouldn't be automatic conversion at all.
> b) The codepage of a string shouldn't change when you assign a string
with another codepage, just rise an error.
> c) Corollary of previous premise
On Wed, 11 May 2016, Santiago A. wrote:
El 11/05/2016 a las 16:38, Michael Van Canneyt escribió:
FPC 3.0 adds unsafe auto-conversions
Why do you think it is unsafe ?
I have an answer for this.
In short:
Different codepage strings and raw strings should be considered
different incompati
El 11/05/2016 a las 16:38, Michael Van Canneyt escribió:
>
>> FPC 3.0 adds unsafe auto-conversions
>
> Why do you think it is unsafe ?
>
I have an answer for this.
In short:
Different codepage strings and raw strings should be considered
different incompatible types. Pascal is a hardtyped language
Andreas Dorn wrote on Wed, 11 May 2016:
All in all Graeme is right. FPC looks pretty much broken to me, too.
For my projects I pulled the emergency-break on anything FPC.
The most serious flaws for me of FPC 3.0 are:
- assuming that it's possible to assign an encoding to every string
- using
On Wed, 11 May 2016, Andreas Dorn wrote:
All in all Graeme is right. FPC looks pretty much broken to me, too.
For my projects I pulled the emergency-break on anything FPC.
The most serious flaws for me of FPC 3.0 are:
- assuming that it's possible to assign an encoding to every string
- usin
All in all Graeme is right. FPC looks pretty much broken to me, too.
For my projects I pulled the emergency-break on anything FPC.
The most serious flaws for me of FPC 3.0 are:
- assuming that it's possible to assign an encoding to every string
- using an (unsafe) guess about the encoding fo
Graeme Geldenhuys wrote on Wed, 11 May 2016:
My test program under FPC 2.6.4 doesn't give problems. It's when that
same program is compiled under FPC 3.0.0 that it does. All due to String
(and thus AnsiString) changing its encoding based on the running
environment.
In FPC 2.6.x, if you use a
On Wed, 11 May 2016, Jonas Maebe wrote:
Michael Van Canneyt wrote on Wed, 11 May 2016:
On Wed, 11 May 2016, Graeme Geldenhuys wrote:
If anybody has the time, I would really like to learn how. Using FPC
3.x. Running the example program in a Latin-1 [console] environment and
still get the c
On 2016-05-11 14:14, Jonas Maebe wrote:
> compared to FPC 2.6.x due to automatic conversions in the RTL and FCL.
> When it is clear that is not true, you are now saying that the
> behaviour of FPC 3.0 is different to FPC 2.6.x if you compile
> different code with each one.
My test program un
Michael Van Canneyt wrote on Wed, 11 May 2016:
On Wed, 11 May 2016, Graeme Geldenhuys wrote:
If anybody has the time, I would really like to learn how. Using FPC
3.x. Running the example program in a Latin-1 [console] environment and
still get the correct data stored in the output.data file.
Graeme Geldenhuys wrote on Wed, 11 May 2016:
On 2016-05-11 13:27, Jonas Maebe wrote:
If you change the string to unicodestring (since
FPC 2.6.4 does not know {$modeswitch unicodestring}), you should get
the same results in FPC 2.6.4 and FPC 3.x
No, because FPC 2.6.4 doesn't do automatic encod
On Wed, 11 May 2016, Graeme Geldenhuys wrote:
On 2016-05-11 13:37, Michael Van Canneyt wrote:
It would not help if we did this: the data would be wrong in the TDataset
buffers, and the result would be worse.
I didn't mean literally search and replace - that would simply be too
easy. ;-) So
On 2016-05-11 13:27, Jonas Maebe wrote:
> If you change the string to unicodestring (since
> FPC 2.6.4 does not know {$modeswitch unicodestring}), you should get
> the same results in FPC 2.6.4 and FPC 3.x
No, because FPC 2.6.4 doesn't do automatic encoding conversions. I would
first have to a
On 2016-05-11 13:37, Michael Van Canneyt wrote:
>
> It would not help if we did this: the data would be wrong in the TDataset
> buffers, and the result would be worse.
I didn't mean literally search and replace - that would simply be too
easy. ;-) Some work and testing would be required, otherwis
On 2016-05-11 12:03, Graeme Geldenhuys wrote:
> I wrote a small
> test program that reads data from a Firebird database where the database
> and field charset is set to UTF8.
For those that want to try the sample application, a backup of the
database (3.7MB in size) can be found at:
http://geld
On Wed, 11 May 2016, Graeme Geldenhuys wrote:
On 2016-05-11 13:07, Michael Van Canneyt wrote:
But what does your program prove ?
See below...
You're only proving that a conversion happens when you do
s := fieldByName('somefield').asString;
I'm proving that using the String type anywher
That's because you have {$modeswitch unicodestring}, so
string=unicodestring.
This is answer to my question :-)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
I just double checked my results again. With u: String variable and
compiled with FPC 3.0 and running in a Latin-1 environment, data is
completely corrupted.
It will be good to know where this happens.
Because AFAIK fcl-db internaly uses AnsiString/String so assigning
between them should no
Graeme Geldenhuys wrote on Wed, 11 May 2016:
On 2016-05-11 13:05, Jonas Maebe wrote:
Your concern is with utf8string, not with string/ansistring.
UTF8String is a AnsiString with utf-8 code page set.
If you
only use string/ansistring/unicodestring, then the behaviour of your
program will be id
On 2016-05-11 13:07, Michael Van Canneyt wrote:
>
> But what does your program prove ?
See below...
> You're only proving that a conversion happens when you do
> s := fieldByName('somefield').asString;
I'm proving that using the String type anywhere in the RTL and FCL is
now terrible. If the FP
On 2016-05-11 13:05, Jonas Maebe wrote:
>
> Your concern is with utf8string, not with string/ansistring.
UTF8String is a AnsiString with utf-8 code page set.
If you
> only use string/ansistring/unicodestring, then the behaviour of your
> program will be identical with FPC 2.6.4 and 3.0. With
On Wed, 11 May 2016, Graeme Geldenhuys wrote:
Hi,
Here is an example [proof if you will] of the problem. I wrote a small
test program that reads data from a Firebird database where the database
and field charset is set to UTF8.
I compile the program, then run it. No recompiles between the tw
On 2016-05-11 12:03, Graeme Geldenhuys wrote:
> Console output:
>
> [unicode_test]$ export LANG=en_US.UTF-8
> [unicode_test]$ ./unicodetest
> 65001
>
> [unicode_test]$ export LANG=en_US.ISO8859-1
> [unicode_test]$ ./unicodetest
> 28591
Just to add, compiling that test program with FPC 2.6.4 I ge
Graeme Geldenhuys wrote on Wed, 11 May 2016:
I'm honestly trying very hard to understand the string changes
implemented in FPC 3.x, and the best way to use it going forward. In
this example I tried everything I learned from the recent mailing list
discussions. My concern with the usage of Strin
Hi,
Here is an example [proof if you will] of the problem. I wrote a small
test program that reads data from a Firebird database where the database
and field charset is set to UTF8.
I compile the program, then run it. No recompiles between the two runs.
The first run my system is set to have a UT
31 matches
Mail list logo
