what's the fastest way to validate a simple pointer ?

[whatsup]

without using assembler

[Laksen]

Using the assigned function?

[theo]

MyPtr<>nil

[User137]

Anyone know what the assigned() function actually does? Once when i replaced Assigned() with simple ptr<>nil my application speeded up tremendously.

[bflm]

Anyone know what the assigned() function actually does? Once when i replaced Assigned() with simple ptr<>nil my application speeded up tremendously.

Depends on what is/how you define pointer "validation". For common pointers (roughly those where pointee is a value) comparing to a nil constant is quite OK. But there are other pointer kinds in FPC as well. Comparing a function pointer to nil can either give you a compile error (the pointed to function's return type is not compatible) or you are now comparing the nil const with the result returned from an invocation of a function pointed to. Here comes the Assigned() which will always compare the value of the pointer against nil and will never invoke anything else in the case of a function pointer.

The function pointer vs value of the pointed to function can be made unambiguous by making () mandatory in the case of the function (via pointer) call, but originally Delphi allowed it w/o the parenthesis, creating a semantic ambiguity leading to introduction of Assigned. In contrast, in the FPCObj mode (at least and AFAIK), the invocation of a function via pointer is unambiguous, you always have to use F().

[Phil]

Here comes the Assigned() which will always compare the value of the pointer against nil and will never invoke anything else in the case of a function pointer.

As bflm points out, using Assigned is generally preferable to testing for nil. There's no speed penalty for using it.

We're assuming the original post refers to nil pointers. Pointers can also be invalid if they don't point to anything - example a memory leak. Not sure how or if those can be validated outside of utilities like leaks (OS X) or something similar.

Thanks.

-Phil

[xenblaise]

MyPtr<>nil

is that serious?


How about this;
Type
PmyStreamRec = ^myStreamRec;
myStreamRec = packed record
id: Integer;
name: String;
end;
...
var
RecStream:PmyStreamRec;
MemStream: TMemoryStream;

//Write
while not X.EOF do
  begin
  New(RecStream);
  RecStream^.id := xxx;
  RecStream^.name := yyy;
  MemStream.WriteBuffer(RecStream, sizeOF(RecStream));
  X.Next;
  end;

//Read
  MemStream.Position := 0;
  while (MemStream.Position < MemStream.Size) do
  begin
  MemStream.ReadBuffer(RecStream, SizeOf(RecStream));
  XiD := RecStream.id;
  nAme  := RecStream.name;
  end;

iS there a faster way to Read and Write that?

Again, sorry  didn't catch that, can this be applied to my code above to make it faster?

MyPtr<>nil

How?

[bflm]

Again, sorry  didn't catch that, can this be applied to my code above to make it faster?

MyPtr<>nil

How?

I have no idea what you're talking about, I failed to see a connection with the OP problem.

The only thing I understand is that that this code

Code: [Select]


//Read
  MemStream.Position := 0;
  while (MemStream.Position < MemStream.Size) do
  begin
  MemStream.ReadBuffer(RecStream, SizeOf(RecStream));
  XiD := RecStream.id;
  nAme  := RecStream.name;
  end;

can not work (in general situation) at all as the field name has type String. The name field becames easily invalid with a memory leak if it had before any non empty string. Similarly the preceding code for write doesn't "write" the value of the name field, only the refcounted pointer to it. That may "work" within a single process but reading it back from a stream breaks the reference counting.

I'm probably missing something.

[xenblaise]

Actually the code really works. Tested.

Code: [Select]

Type
PmyStreamRec = ^myStreamRec;
myStreamRec = packed record
id: Integer;
name: String;
end;
...
var
RecStream:PmyStreamRec;
MemStream: TMemoryStream;

//Write
while not X.EOF do
  begin
  New(RecStream);
  RecStream^.id := X.FieldByName('id').AsInteger;
  RecStream^.name := X.FieldByName('name').AsString;
  MemStream.WriteBuffer(RecStream, sizeOF(RecStream));
  X.Next;
  end;

//Read
  MemStream.Position := 0;
  while (MemStream.Position < MemStream.Size) do
  begin
  MemStream.ReadBuffer(RecStream, SizeOf(RecStream));
  XiD := RecStream.id;
  nAme  := RecStream.name;
  memo1.lines.Add('iD: ' + intTosTr(XiD) + '  nAme: ' + nAme);
  end;

Using the pointer surely gets the EXACT data when handling large records.

The speed is OK, but I need to apply some technique if possible.
Like;v I just don't understand how to use this, or if can be used in my code above.

MyPtr<>nil

[Bart]

As bfml poited out to you, when type string = AnsiString (when using {$H+} or {$mode delphi}) , then SizeOf(myStreamRec) = 6 (at least on my OS).
The record that you write to on file will contain only the integer and the pointer to the string.
When you read back in the same session you might get lucky and all goes well, but in general it's not gonna work.

When type string = ShortString (when using {$H-}) then it's probably OK. SizeOf(myStreamRec) = 258 in this case.

Try something like this:

Code: [Select]

  RecStream^.id := X.FieldByName('id').AsInteger;
  RecStream^.name := X.FieldByName('name').AsString;
  MemStream.WriteBuffer(RecStream.id, sizeOF(RecStream.id));
  MemStream.WriteBuffer(RecStream.name[1], Length(RecStream.name));

or use ShortStrings.

Bart

[xenblaise]

MemStream.WriteBuffer(RecStream.id, sizeOF(RecStream.id));
MemStream.WriteBuffer(RecStream.name[1], Length(RecStream.name));

is faster than

MemStream.WriteBuffer(RecStream, sizeOF(RecStream));

I hope that's correct.

How about when it reads?
MemStream.ReadBuffer(RecStream.iD, SizeOf(RecStream.iD)); ?

Like that also?
 


Thanks

[whatsup]

MyPtr<>nil

thank you very much
i couldn't expect a better answer

since in my case this is the only thing i want to test

[whatsup]

There's no speed penalty for using it.

sure there is, and that's why i asked for the fastest way.

UNLESS assigned is an inline function/macro that does exacly what
i expected it to do in my case.