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 variables with ANSISTRNG? It's likely that
I would solve a lot of future problems that I don't even know I have yet if I did this.
Is there any reason not to change all the Strings to Ansistrings?

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.

So maybe this could be a problem. Is there a way to make a file of strings that are not limited to 255 characters?

Also I can make records that contain Ansistrings, but I can't make files of those records, for the same reason as above.

James

On 2023-12-19 12:36, James Richters via fpc-pascal wrote:

Hello James,

.
.

You may be surprised, but FPC (and even earlier also Delphi) provides you with multiple ways allowing you to use variables declared as "string" without length limits (i.e. using type ansistring or unicodestring underneath). There are compiler directives {$H+} and {$UNICODESTRINGS} doing exactly that, and there are also modes {$MODE DELPHI} and {$MODE DELPHIUNICODE} which (among others) trigger the previously mentioned compiler directives (the difference is that the modes have wider impact, not only the underlying type used for variables, parameters, etc., of type string).

In order to answer you question about potential reasons for not using ansistring or unicodestring for everything, it's useful to understand the associated differences:

1) Ansistring and Unicodestring are reference counted. This brings some computational overhead potentially impacting performance - this may not be important in many cases, but there are also cases for which this may be very important.

2) Ansistring and Unicodestring are technically pointers to structures allocated on the heap rather than directly storing the string itself with preallocated number of characters. There are scenarios for which this difference is important (e.g. when interfacing with operating system API calls or 3rd party code in general).

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.).

Tomas

I would just define the file as 'Text'.
Can then Readln into an Ansistring.

Cheers,
Peter

A "file of" must have a fixed size type.

"file of word", reads 2 byte (1 word) for each entry.

Shortstring always occupies 256 bytes
String[20] always 21 bytes
Even if such a string just contains "abc" it will have the full amount of bytes used in the file.

For ansistring that is not possible. It can have millions of chars, and you can't have each entry use 2^32 bytes.
If they don't have linebreaks, then you can just readln/writeln to/from a text file.

Mind: You can't replace just one string in the file by a different value, if the new string-value has a different length => then the entire rest of the file needs to be moved.

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 AnsiString that is empty then you get a rangecheck error, which is understandable as there is nothing in character 1, but If MyString is just a String and is empty then it runs just fine.... so I have a lot of those kinds of things.
So some of these I just changed them back to a string for now, but If I want to change them anyway then I just do
If (Length(MyString)>0) and (MyString[1]='~') Then ...

And that fixes the issue as well, and it's probably better code as I shouldn't be testing a particular character if there isn't a character there.

James