Re: [fpc-pascal] Strings greater than 255 characters

2023-12-19 Thread James Richters via fpc-pascal
>3) There are some other smaller differences impacting compatibility with code designed to work with type shortstring (e.g. related to used character sets etc.). Here's a difference I discovered... I see that if I try to do something like: If MyString[1]='~' Then ... If MyString is an AnsiStri

Re: [fpc-pascal] Strings greater than 255 characters

2023-12-19 Thread Martin Frb via fpc-pascal
On 19/12/2023 12:36, James Richters via fpc-pascal wrote: I did notice that I cannot have a file of Ansistrings… Myfile : File of Ansistring; Causes a compiler error: Error: Typed files cannot contain reference-counted types. A "file of" must have a fixed size type. "file of word", reads

Re: [fpc-pascal] Strings greater than 255 characters

2023-12-19 Thread Peter B via fpc-pascal
On 19/12/2023 11:36, James Richters via fpc-pascal wrote: I did notice that I cannot have a file of Ansistrings… Myfile : File of Ansistring; Causes a compiler error: Error: Typed files cannot contain reference-counted types. I would just define the file as 'Text'. Can then Readln into an

Re: [fpc-pascal] Strings greater than 255 characters

2023-12-19 Thread Tomas Hajny via fpc-pascal
On 2023-12-19 12:36, James Richters via fpc-pascal wrote: Hello James, I keep getting bit by using STRING variables then trying to store more than 255 characters. My typical way to fix this is to just change it to an ANSISTRING. I'm wondering if there is any reason not to do this the other w

[fpc-pascal] Strings greater than 255 characters

2023-12-19 Thread James Richters via fpc-pascal
I keep getting bit by using STRING variables then trying to store more than 255 characters. My typical way to fix this is to just change it to an ANSISTRING. I'm wondering if there is any reason not to do this the other way around and just go through My entire program and replace all the STRING

Re: [fpc-pascal] Strings

2013-07-22 Thread Michael Schnell
On 07/20/2013 01:19 PM, Noah Silva wrote: Wait, I'm slightly confused. It seems people are talking about two different things: 1. Continuous memory as seen by the program running. 2. Actually physically contiguous memory. If you don't do hardware related things like DMA, you don't need to both

Re: [fpc-pascal] Strings

2013-07-20 Thread Noah Silva
Hi everyone, Wait, I'm slightly confused. It seems people are talking about two different things: 1. Continuous memory as seen by the program running. 2. Actually physically contiguous memory. It was my understanding that strings and dynamic arrays are allocated as a single block, and thus from

Re: [fpc-pascal] Strings

2013-07-16 Thread Carsten Bager
My code was just an example, to illustrate what I was aiming at. It is not actually used. But I think you have a point Carsten > Why not just skip all the encoding uncertainity of strings and use an > array of byte/char? > > It'll probably be a lot faster too _

Re: [fpc-pascal] Strings

2013-07-16 Thread Carsten Bager
> Of course the OS is free to use the mapped hardware RAM address in a way > that for DMA the string content might come in separate chunks. > > Is this what you mean ? > > - Michael Yes Thanks Carsten ___ fpc-pascal maillist - fpc-pascal@lists.fre

Re: [fpc-pascal] Strings

2013-07-16 Thread Marco van de Voort
In our previous episode, Carsten Bager said: > Function Sum(p:pointer; len:LongInt):LongInt; > Type > a_typ=array[0..pred(maxLongInt)] of byte; > a=^a_typ; > var > i:LongInt; > Begin > result:=0; > for i:=0 to len do > result:=result+a(p)^[i]; > End; 0..len is len+1 items. > > Pro

Re: [fpc-pascal] Strings

2013-07-16 Thread Jeppe Græsdal Johansen
Why not just skip all the encoding uncertainity of strings and use an array of byte/char? It'll probably be a lot faster too Den 16-07-2013 12:17, Carsten Bager skrev: Hi I have a question about dynamic strings and memory allocation. If you look at my example underneath, I depend on that a dyn

Re: [fpc-pascal] Strings

2013-07-16 Thread Michael Van Canneyt
On Tue, 16 Jul 2013, Carsten Bager wrote: Hi I have a question about dynamic strings and memory allocation. If you look at my example underneath, I depend on that a dynamic string always is assigned memory space in one connected block. But will that always be the case in various operating sy

Re: [fpc-pascal] Strings

2013-07-16 Thread Michael Schnell
On 07/16/2013 12:17 PM, Carsten Bager wrote: If you look at my example underneath, I depend on that a dynamic string always is assigned memory space in one connected block. As the compiler allows for assigning a string to a pchar, the strings need to be compatible to C strings. Thus: - The con

[fpc-pascal] Strings

2013-07-16 Thread Carsten Bager
Hi I have a question about dynamic strings and memory allocation. If you look at my example underneath, I depend on that a dynamic string always is assigned memory space in one connected block. But will that always be the case in various operating systems. Carsten Function Sum(p:pointer; le

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread dev . dliw
Hi, that's great news... Thanks for the effort to clarify, d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread Marco van de Voort
In our previous episode, Michael Van Canneyt said: > > > > Rule of thumb: anything global must be passed on the cmdline everytime, and > > directives are only for unit level. (a few special ones for library units > > like $libsuffix excluded) > > While this is correct, I think it is possible to co

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread Michael Van Canneyt
On Sat, 22 Dec 2012, Marco van de Voort wrote: In our previous episode, dev.d...@gmail.com said: Users can define the internal type with e.g. {$STRING UTF8} for their *whole* project. This is technically impossible. Both FPC and Lazarus don't have a complete overview of all units and includ

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread Marco van de Voort
In our previous episode, dev.d...@gmail.com said: > Users can define the internal type with e.g. {$STRING UTF8} for their *whole* > project. This is technically impossible. Both FPC and Lazarus don't have a complete overview of all units and includefiles in a project, and compiles can also be par

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread Marco van de Voort
In our previous episode, Michael Van Canneyt said: > - The {$H } directive will be extended so you can choose which string type > you need per unit. >(ansi/wide/utf16/utf8...) >This is different from Delphi, where you don't have this choice: > String=Widestring. unicodestring, actually

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread Michael Van Canneyt
On Sat, 22 Dec 2012, luiz americo pereira camara wrote: Em 22/12/2012 09:55, "Michael Van Canneyt" escreveu: > > > > Because of the requirement for backwards compatibility with FPC itself, we'll make 2 RTLs: one backwards compatible, one with the new unicode string. > It will be possible

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread luiz americo pereira camara
Em 22/12/2012 09:55, "Michael Van Canneyt" escreveu: > > > > Because of the requirement for backwards compatibility with FPC itself, we'll make 2 RTLs: one backwards compatible, one with the new unicode string. > It will be possible to compile a utf8 rtl? There will be a RtlString ? Luiz > > _

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread Paul Ishenin
22.12.12, 22:58, Martin Schreiber пишет: That was so in the beginning but Delphi later changed it. So a Delphi UnicodeString variable currently allways is utf-16 encoded. The same in FPC. Best regards, Paul Ishenin ___ fpc-pascal maillist - fpc-p

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread Martin Schreiber
On Saturday 22 December 2012 15:45:13 Michael Van Canneyt wrote: > On Sat, 22 Dec 2012, Martin Schreiber wrote: > > UnicodeString or codepage aware cpstrnew? > > 'codepage aware' just means that you can specify a charsize/codepage. > A unicode string is just one type of codepage aware string. > (u

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread Michael Van Canneyt
On Sat, 22 Dec 2012, Martin Schreiber wrote: On Saturday 22 December 2012 12:55:12 Michael Van Canneyt wrote: [...] - The {$H } directive will be extended so you can choose which string type you need per unit. (ansi/wide/utf16/utf8...)    This is different from Delphi, where you don't have th

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread Martin Schreiber
On Saturday 22 December 2012 12:55:12 Michael Van Canneyt wrote: [...] > - The {$H } directive will be extended so you can choose which string type > you need per unit. (ansi/wide/utf16/utf8...) >    This is different from Delphi, where you don't have this choice: > String=Widestring. You probably

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread Michael Van Canneyt
On Sat, 22 Dec 2012, dev.d...@gmail.com wrote: Hi, thx, got it... There will always be conversion if 1) a unit specifies a string type by itself. 2) the unit comes in compiled form. One more question: If a particular unit (maybe 3rd party) does not define its string type, what string type

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread dev . dliw
Hi, thx, got it... > There will always be conversion if > 1) a unit specifies a string type by itself. > 2) the unit comes in compiled form. One more question: If a particular unit (maybe 3rd party) does not define its string type, what string type is used: (a) the type defined in project, (b) a

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread Michael Van Canneyt
On Sat, 22 Dec 2012, dev.d...@gmail.com wrote: Hi, thanks for the quick reply. So the direction seems to be quite clear... ... unfortunately this seemingly wasn't communicated clearly enough to the surroundings. Because of the requirement for backwards compatibility with FPC itself, we'll m

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread dev . dliw
Hi, thanks for the quick reply. So the direction seems to be quite clear... ... unfortunately this seemingly wasn't communicated clearly enough to the surroundings. >Because of the requirement for backwards compatibility with FPC itself, >we'll make 2 RTLs: one backwards compatible, one with th

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread dev . dliw
Hi, > > Users can define the internal type with e.g. {$STRING UTF8} for their > > *whole* project. > > Should that (*whole* project) include also the "3rd party" units (with > available sourcecode)? Yes, that's the idea... ... the only problem is, that many still use old style "hacking", this of

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread Michael Van Canneyt
On Sat, 22 Dec 2012, dev.d...@gmail.com wrote: Hi, concerning the string topic, for me (using fpc since 2.0.4 on a regular basis; TP experience ~ average user) there really should be an decision what way to go as early as possible. - We'll implement the capacity to have a code-page aware str

Re: [fpc-pascal] Strings - suggestions

2012-12-22 Thread Rainer Stratmann
Am Saturday 22 December 2012 12:26:09 schrieb dev.d...@gmail.com: > Users can define the internal type with e.g. {$STRING UTF8} for their > *whole* project. Should that (*whole* project) include also the "3rd party" units (with available sourcecode)? __

[fpc-pascal] Strings - suggestions

2012-12-22 Thread dev . dliw
Hi, concerning the string topic, for me (using fpc since 2.0.4 on a regular basis; TP experience ~ average user) there really should be an decision what way to go as early as possible. I'm not ranting and I know, that I'm not in the position to demand anything... [I would really like to help, but

Re: [fpc-pascal] Strings and objects crossing dll boundaries

2012-06-14 Thread Mark Morgan Lloyd
kyan wrote: Hello all, A couple of questions regarding handling of strings, dynamic arrays and objects -especially exceptions- when writing programs that use shared libraries (.dll, .so). This seems to be a hot topic at the moment. In Delphi we have the option of either using packages to ens

Re: [fpc-pascal] Strings and objects crossing dll boundaries

2012-06-14 Thread Marco van de Voort
In our previous episode, kyan said: > > A couple of questions regarding handling of strings, dynamic arrays > and objects -especially exceptions- when writing programs that use > shared libraries (.dll, .so). > > In Delphi we have the option of either using packages to ensure that > there is only

[fpc-pascal] Strings and objects crossing dll boundaries

2012-06-14 Thread kyan
Hello all, A couple of questions regarding handling of strings, dynamic arrays and objects -especially exceptions- when writing programs that use shared libraries (.dll, .so). In Delphi we have the option of either using packages to ensure that there is only one instance of the memory allocator o