string pointers behaves different in loop

[Goodman H__]

Greeings,

I am so excited that pointers in fp have the same power as in C.Considering below code:

Code: [Select]

procedure TestPointer;
var
  str:string;
  pstr:pstring;
begin
 
  str:='This is a very very long string that test string pointers';
  pstr:=@str;
  while true do
  begin
       write(pstr^+' ');
       pstr:=pstr+1;
       if pstr=nil then break;
  end;
  writeln;

end;        


Using the above while...do loop I got an exception after the correct output.The error message is:

Code: [Select]

Project project1.exe raised exception class 'External:SIGSEGV'.

But when I use repeat ...until loop it works fine with no problem:

Code: [Select]

...
 repeat
       write(pstr^+' ');
       pstr:=pstr+1;
  until pstr<>nil;
...

So I am really confused what's the logic problem in the while...do loop solution which caused the exception.

It would be grateful if you would like to help.          

[Leledumbo]

String is an opaque type. It's a simple array of char in default mode, but pointer to a record (with a longint indicating the length, and a dynamic array containing the characters) in objfpc and delphi mode. I don't recommend using pointers to strings at all. Use var parameters instead.

[Goodman H__]

String is an opaque type. It's a simple array of char in default mode, but pointer to a record (with a longint indicating the length, and a dynamic array containing the characters) in objfpc and delphi mode. I don't recommend using pointers to strings at all. Use var parameters instead.

Thanks for the reply.My first intention to use pointers to strings is the compatability and  performance as c to interact with OS calls with the power of pointer arithmetic operations.

Can I ask what you mean by 'use var parameters instead', a piece of code segment please?

[theo]

You can use the PChar type which is exactly the same as char* in C.
You can convert String <> Pchar like:

APChar:=PChar(AStr);
AStr:=APChar; 

[Martin_fr]

I think  it is pure luck that the repeat doesn't crash.

 if pstr=nil then break;
  until pstr<>nil;

pstr may be nil (if the string is empty to begin with). so you must test upfront

pstr will not become nil, if you reach the end of the str.

if pstr^ = #0 then

should help

[Goodman H__]

I think  it is pure luck that the repeat doesn't crash.

 if pstr=nil then break;
  until pstr<>nil;

pstr may be nil (if the string is empty to begin with). so you must test upfront

pstr will not become nil, if you reach the end of the str.

if pstr^ = #0 then

should help

Thanks a lot.After tried several time with all the above possibilities,I am getting more and more confused.For example,if pstr^=#0 then almost leads to the same result as pstr=nil,so I am so confused with pointers to strings...Studying...

[Martin_fr]

Another possible mistake from your original post:

 pstr:=@str;

This may not may not give you a pointer to the chars in the string.

Depending on compiler settings, string is either:
shortstring
ansistring

shortstring always has a fixed length, and therefore a shortstring can be at a fixed (and known at compile time) location in memory.

Ansistring can grow to any size. Memory must be allocated on the fly, once the required amount is known. That means behind the scenes ansistring must do memory management too. And store that info.
AnsiString is internally already a pointer, but normally you never will notice.

var
  sa: AnsiString;
  sb: ShortString[10];

pa := @sa;  // something you never want. a pointer to an internal structure of fpc, may change in new fpc versions, not save to access

pa := @sa[1]; // works, but gives a range check, if the string is empty

pa := Pchar(sa); // always good

pb := @sb; // may work, I don't actually know
pb := @sb[1]; //ok, as long as sb was defined with a len of 1 or more
pb := pchar(pb); // good

pa can be nil, if the sa was empty. That may be unexpected, because you can't do "if pa^ = #0"

since the shortstring has a fixed len pb should never be nil

[marcov]

Whatever the type is,  shortstring or ansistring, incrementing it is never a good idea. 

Even compatibility with C doesn't require pointers. You can perfectly pass an ansistring (read-only) to a C routine.

So maybe you should explain better what exactly you want to accomplish.

[Leledumbo]

My first intention to use pointers to strings is the compatability and  performance as c to interact with OS calls with the power of pointer arithmetic operations.

Pascal strings are actually more powerful and easier to use than C strings (for example, getting string length through strlen() has a complexity of O(n) while Pascal's Length() is only O(1)). Most things can be done without pointers in Pascal, you only need it in rare cases.

Can I ask what you mean by 'use var parameters instead', a piece of code segment please?

Well, if you're using pointers because you want to pass parameters as efficient as possible, then using var (or const) parameters will do the same. Example:

Code: [Select]

// when you call this, a copy of the string will be passed
procedure DoSomethingWithString(s: string);
begin
  s := '';
end;
// when you call this, pointer to the string will be passed
// but you still access is the same way as above.
// use const instead of var to make it readonly but still retaining the efficiency
procedure DoSomethingElseWithString(var s: string);
begin
  s := '';
end;


[Goodman H__]

Whatever the type is,  shortstring or ansistring, incrementing it is never a good idea.  

Even compatibility with C doesn't require pointers. You can perfectly pass an ansistring (read-only) to a C routine.

So maybe you should explain better what exactly you want to accomplish.

for example:

Code: [Select]

typedef struct Stuff__
{
    Stuff__ *next;
    Stuff__ *previous;
    char ***matrix;
}Stuff;
Maybe I would like to matrix to do some rotation operations.And the Stuff should do some basic concatenations the like.

[marcov]

[

for example:

Code: [Select]

typedef struct Stuff__
{
    Stuff__ *next;
    Stuff__ *previous;
    char ***matrix;
}Stuff;
Maybe I would like to matrix to do some rotation operations.And the Stuff should do some basic concatenations the like.

matrix is a pointer to pointer to pointer to char.  But it can be seen as a two dimensional grid of strings, or and array of pointers to 8-bit images.

But in general, optimizing strings to the pointer level does not bring much. This because (ansi)strings are already basically only a small abstraction over array pointers. Because the copy-on-write and length field they can even be faster than naieve array pointer usage.

So assuming you meant a two dimensional matrix of strings, try

Code: [Select]

Type
    PStuff = ^Stuff;
    Stuff = record
      next,
      previous  : PStuff;
      Matrix     : array of array of ansistring; // or just a. of a. of string in Delphi mode
     end;

Besides the string abstraction, this also uses the dynamic array abstraction, which you can read about here:

http://www.freepascal.org/docs-html/ref/refsu14.html#x38-420003.3.1

[Goodman H__]

[

for example:

Code: [Select]

typedef struct Stuff__
{
    Stuff__ *next;
    Stuff__ *previous;
    char ***matrix;
}Stuff;
Maybe I would like to matrix to do some rotation operations.And the Stuff should do some basic concatenations the like.

matrix is a pointer to pointer to pointer to char.  But it can be seen as a two dimensional grid of strings, or and array of pointers to 8-bit images.

But in general, optimizing strings to the pointer level does not bring much. This because (ansi)strings are already basically only a small abstraction over array pointers. Because the copy-on-write and length field they can even be faster than naieve array pointer usage.

So assuming you meant a two dimensional matrix of strings, try

Code: [Select]

Type
    PStuff = ^Stuff;
    Stuff = record
      next,
      previous  : PStuff;
      Matrix     : array of array of ansistring; // or just a. of a. of string in Delphi mode
     end;

Besides the string abstraction, this also uses the dynamic array abstraction, which you can read about here:

http://www.freepascal.org/docs-html/ref/refsu14.html#x38-420003.3.1

This is awesome.

From the dynamic array what I understand is there is an expensive cost everytime the array need resize,but pointers doesn't.Please correct me if I am wrong.Thanks.

[marcov]

From the dynamic array what I understand is there is an expensive cost everytime the array need resize,but pointers doesn't.Please correct me if I am wrong.Thanks.

You are wrong. There is a minimal, insignificant overhead at best. Moreover it is only noticable in the tightest of loops that you can optimize afterwards by, in the tightest loop, _locally_ iterating with pointers through the dyn array.

So just use dyn arrays, and forget the rest till really needed.

[Goodman H__]

From the dynamic array what I understand is there is an expensive cost everytime the array need resize,but pointers doesn't.Please correct me if I am wrong.Thanks.

You are wrong. There is a minimal, insignificant overhead at best. Moreover it is only noticable in the tightest of loops that you can optimize afterwards by, in the tightest loop, _locally_ iterating with pointers through the dyn array.

So just use dyn arrays, and forget the rest till really needed.

Thank you so much.I should study deeper in FP's memory model.