It is supported but why do you do not write else instead of continue in the first continue statement: that is a single instruction on most CPU's? It is simply silly code.
Is this optimal if assuming the data is referred to in multiple occasions in code?
with TActor(Actors.Data[i]) do
Or was pointer reference faster?
pActor:=PActor(@Actors.Data[i]);
Why would the developers be so stupid as to make native array indexing slower than a protracted pointer construction ? It is an old claim that pointer indexing is faster, and this may have been true long ago, but in my own benchmarks I always found the native approach a bit faster... but we are talking almost unmeasurable quantitities, +/-5% maybe. As said above, with the only exception of multidimensional arrays.
First of all "using pointer" can refer to many different things.
What about "Binary Trees", "HashTables" or "Linked List of Dynamic Arrays" or "Databases"... I guess I read this on stackoverflow or somewhere else...
Or some ready to use FreePascal Lists: TFPList or TFPHashList ...
Still the original question.. There is no clear info on how any pascal compilers will handle such continues in loops?
i'm still wondering if "with TActor(Actors.Data) do" / or "pActor:=PActor(@Actors.Data);" method is faster..
I mean... Why can you just see, what asm code compiler generates?Your pascal code of procedure Test1 and procedure Test2 are exactly equivalent and its compiled by FPC and then disassembled code seems too. Conclusion from code efficiency point of view - there is no difference between presented Test1 and Test2. I guess that using "continue" (or "break") is a C-people habit and may lead to errors when chosen to be used in nested iterations.Find 10 differences. Ignore beginning of procedure Test1, as broken debugger starts disassembling from $004253AF, not from $004253B0, as it should.
function Test1:Integer; var I:Integer; begin Result := 0; for I := 0 to 100 do begin if Random(100) >= 50 then begin if Random(100) >= 50 then begin Inc(Result); end; end; end; end; function Test2:Integer; var I:Integer; begin Result := 0; for I := 0 to 100 do begin if Random(100) < 50 then Continue; if Random(100) < 50 then Continue; Inc(Result); end; end;
well, do like .....Nothing understood, OK - my personal limits.
@Handoko1. "continue" is not a reserved pascal word, we can declare "procedure continue;" and compile it with no problem (I know - a bad idea but possible);
Note that there are two things that are important:
- Continue is a procedure... See the documentation (RTFM) https://www.freepascal.org/docs-html/rtl/system/continue.html
- A simple in-place boolean evaluation is usually faster than a procedure call by definition.
So from an algorithmic point of view the first (one less continue) should be faster, although the compiler can optimize it to be about the same code.
BTW: I have hardly ever seen code where continue could not be rewritten in a better way. It is basically a shortcut forlousylazy programmers.
And if you are curious: always examine the generated assembler as someone mentioned before. And with different optimizations: that can make a huge difference.
But it starts with a good algorithm.
1. "continue" is not a reserved pascal word, we can declare "procedure continue;" and compile it with no problem (I know - a bad idea but possible);Well: https://www.freepascal.org/docs-html/rtl/system/continue.html
Your pascal code of procedure Test1 and procedure Test2 are exactly equivalent and its compiled by FPC and then disassembled code seems too. Conclusion from code efficiency point of view - there is no difference between presented Test1 and Test2. I guess that using "continue" (or "break") is a C-people habit and may lead to errors when chosen to be used in nested iterations.