Re: [fpc-pascal] about dynamic array -- p
Denis, you need to get up to speed on , since this is one of the fundamental (and better) differences of pascal. You'll find the typing system actually helps you a lot. FYI, class is one of the possible types. Basically in Pascal, some types are basic: integer, real, some types are structured: records array, some types are objects (coming from TP/BP), some types are classes and interfaces. There are also some special types like variants. You've also seen the difference between static and dynamic types. Please look up the reference manual for that here: ftp://ftp.freepascal.org/pub/*fpc*/docs-pdf/ref.pdf About the RTL: you'll find a good manual here: ftp://ftp.freepascal.org/pub/*fpc*/docs-pdf/rtl.pdf About TList: it's item type is a untyped pointer, so you can't do anything with the results unless you type it first as mentioned. TObjectList, TComponentList, etc all derive from TList and provide a typed item. It's a good idea for you, if you need it often, to derive your own TIntegerList from TList (or any other container in Cntnrs or elsewhere). You'll find many tutorials on the web, where TIntegerList is provided. With the generics now available in FPC, it's also easy to have a whole hierarchy of TGenericLists which could be easily instanciated to TIntegerList as needed. Out of FPC/Lazarus, there are excellent container libraries, that can reduce your workload. Most of what you need is already there. Decal is one. Best regards, Thierry spir ☣ wrote: On Fri, 7 May 2010 06:10:30 +0200 cobines wrote: PS : I also need the pointer's mediation when a func/proc expects a (typed) element. Must rewrite the code to use an element pointer as parameter (and pass a pointer from the list). This is more annoying since it obscures the func/proc's signature. Is the source of this issue really that these pointers are untyped? If yes, maybe a way to get rid of such noise would be to subtype TFPList into a list of typed pointers? (I don't know yet how to use fpc's type system. So new in this domain I have no idea what the difference between type & class may be ;-) But this will come soon, I guess...) Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] about dynamic array
> c> TList wraps TFPList, which is based internally on an array. So access > c> is fast; insertion, deletion not. > > But it is faster than inserting elements in a dynamic array (unless > reference counted ones) because it usually moves less amount of data > (4/8 bytes per element). Implementing a dynamic array via a list implementation which is based on a dynamic array. Sure, that's faster. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[4]: [fpc-pascal] about dynamic array
Hello FPC-Pascal, Saturday, May 8, 2010, 1:26:09 PM, you wrote: >> But it is faster than inserting elements in a dynamic array (unless >> reference counted ones) because it usually moves less amount of data >> (4/8 bytes per element). VH> Implementing a dynamic array via a list implementation which VH> is based on a dynamic array. Sure, that's faster. Ok, let me known which operation is faster: type ItemOfArray=record TheData: array [0..4095] of BYTE; end; 1) TheArray: array of ItemArray; AnyItem: ItemOfArray; [...] for j:=0 to 1000 do begin SetLength(TheArray,j+1); TheArray[j]:=AnyItem; end; [...] Now here add the code to remove element zero from the array and move down the upper elements. 2) TheList: TList; AnyItem: ItemOfArray; p: Pointer; [...] for j:=0 to 1000 do begin GetMem(p,Sizeof(AnyItem)); TheList.Add(p); end; [...] p:=TheList[0]; FreeMem(p); TheList.Remove(0); -- Remember that the user wants to have an array which could be extended and that allow fast insertion and remove. Of course it would be faster using an array of pointers, but TList will force the user to use an array of pointer, while a dynamic array will not as it can be used with the record type directly. IMHO the discussion was about how help the user to reach an objetive, not how to reach the objetive in the most efficient way but forcing the user to learn the inners of dynamic array. Remember the begins, "move (dynarray,...,...)" do not work "as expected". If you think that have a better proposal, write it... I can have some basic skills at some points in the pascal world, but I'm not stupid at such level to not known that a dynamic array (or similar) is being used in the background of TFPList. -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpDoc Question
Does fpDoc per chance understand the markup used by pasdoc? Specifically, I
used comments like this:
{: Particularly useful when applied to THusband or TBoyfriend. }
ICleaner interface
procedure CleanAfterSelf;
end;
{: Particularly useful when applied to TWife or TGirlfriend. }
IGymnast = interface
procedure AssumeRandomFlexiblePosition;
end;
The colon after the opening brace tags at as a comment to actually render
whereas a comment without the ":" does not get generated.
--
Warm Regards,
Lee
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[4]: [fpc-pascal] about dynamic array
> 1) > TheArray: array of ItemArray; > AnyItem: ItemOfArray; > [...] > for j:=0 to 1000 do begin >SetLength(TheArray,j+1); >TheArray[j]:=AnyItem; > end; > [...] About 1000 GetMem operations (and 1000 assignments which aren't there in the code below, so I won't count them). > Now here add the code to remove element zero from the array and move > down the upper elements. One GetMem, one FreeMem and a (hopefully) fast memory move. > 2) > TheList: TList; > AnyItem: ItemOfArray; > p: Pointer; > [...] > for j:=0 to 1000 do begin > GetMem(p,Sizeof(AnyItem)); > TheList.Add(p); > end; About 1000 GetMems, and potentially another 1000 for extending the list (yes, the internals are more optimized, yet there /will/ be additional calls to GetMem). > [...] > p:=TheList[0]; > FreeMem(p); > TheList.Remove(0); One explicit FreeMem, one potential FreeMem for resizing the list and a (hopefully) fast memory move. > IMHO the discussion was about how help the user to reach an > objetive, not how to reach the objetive in the most efficient way > but forcing the user to learn the inners of dynamic array. And the statement was that using TList would be faster. > I can have some basic skills at some points in the pascal world, but > I'm not stupid at such level to not known that a dynamic array (or > similar) is being used in the background of TFPList. So, apart from a possibly more optimized implementation (like not changing the allocated memory size on each single insertion/deletion) how do you come up with the idea that adding another layer would make it faster? Vinzent. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[4]: [fpc-pascal] about dynamic array
On 08 May 2010, at 16:42, Vinzent Höfler wrote: >> 1) >> TheArray: array of ItemArray; >> AnyItem: ItemOfArray; >> [...] >> for j:=0 to 1000 do begin >> SetLength(TheArray,j+1); >> TheArray[j]:=AnyItem; >> end; >> [...] > > About 1000 GetMem operations (and 1000 assignments which aren't there in the > code below, so I won't count them). And quite a few memory moves (depending on how unlucky you are regarding memory fragmentation and how the heap manager handles things). >> 2) >> TheList: TList; >> AnyItem: ItemOfArray; >> p: Pointer; >> [...] >> for j:=0 to 1000 do begin >>GetMem(p,Sizeof(AnyItem)); >>TheList.Add(p); >> end; > > About 1000 GetMems, and potentially another 1000 for extending the list (yes, > the internals are more optimized, yet there /will/ be additional calls to > GetMem). Yes, about 20. >> [...] >> p:=TheList[0]; >> FreeMem(p); >> TheList.Remove(0); > > One explicit FreeMem, one potential FreeMem for resizing the list Which happens quite rarely, since it's only done if the list is half empty. >> IMHO the discussion was about how help the user to reach an >> objetive, not how to reach the objetive in the most efficient way >> but forcing the user to learn the inners of dynamic array. > > And the statement was that using TList would be faster. And depending on the usage patterns and the size of the elements stored in the array, it probably can be. That's all he was saying, and only as a side remark in the context of the discussion (which was meanly to steer away a new programmer from dynamic arrays to tfplist, which I think is a good idea). Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpDoc Question
On 8 May 2010 15:53, Lee Jenkins wrote: > > Does fpDoc per chance understand the markup used by pasdoc? Specifically, I > used comments like this: fpdoc doesn't use comments from inside the source code. Instead it reads the comments from an external XML file and merging it with the source code to generate the final output. Lazarus's Tooltip Help does read from both external XML and code comments, but you cannot export those tooltip help to some help format. The age old debate (similar to spaces or tabs used as formatting). I much prefer external help, because to have detailed help and that help is as code comments, your code because very quickly unreadable. tiOPF's code comments help is already a borderline case. It should be the job of the IDE to make help available as tooltips, help window etc - all without the need for code comments. Lazarus IDE shows this is quite possible and does a fairly good job of it. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpDoc Question
Graeme Geldenhuys wrote: On 8 May 2010 15:53, Lee Jenkins wrote: Does fpDoc per chance understand the markup used by pasdoc? Specifically, I used comments like this: fpdoc doesn't use comments from inside the source code. Instead it reads the comments from an external XML file and merging it with the source code to generate the final output. Lazarus's Tooltip Help does read from both external XML and code comments, but you cannot export those tooltip help to some help format. The age old debate (similar to spaces or tabs used as formatting). I much prefer external help, because to have detailed help and that help is as code comments, your code because very quickly unreadable. tiOPF's code comments help is already a borderline case. It should be the job of the IDE to make help available as tooltips, help window etc - all without the need for code comments. Lazarus IDE shows this is quite possible and does a fairly good job of it. Ah, that right. I looked at it once, but almost all of my fpc code is shared with delphi so I've been using pasdoc for a while now. Just curious. Thanks again. -- Warm Regards, Lee ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[6]: [fpc-pascal] about dynamic array
Hello FPC-Pascal, Saturday, May 8, 2010, 5:07:12 PM, you wrote: JM> And depending on the usage patterns and the size of the JM> elements stored in the array, it probably can be. That's all he JM> was saying, and only as a side remark in the context of the JM> discussion (which was meanly to steer away a new programmer from JM> dynamic arrays to tfplist, which I think is a good idea). Thank you, at least one catch my whole idea about when TList can be faster that dynamic array or a plain GetMem for the array. -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[6]: [fpc-pascal] about dynamic array
Hello FPC-Pascal, Saturday, May 8, 2010, 4:42:46 PM, you wrote: VH> So, apart from a possibly more optimized implementation (like VH> not changing the allocated memory size on each single VH> insertion/deletion) how do you come up with the idea that adding VH> another layer would make it faster? Because it is not "another layer", is a different implementation. You say that my implement was not fair play as I use "SetLength" inside the loop, but the user request fast insertion/deletion so he do not known in advance the amount of items in the array. The code to insert something in a Dyn array is more complex than a remove in TList. Using dyn arrays and some helper functions to insert/delete elements would be faster and using a helper variable to get the amount of cached entries (not filled) and real entries will end in faster code for sure, but more complex from the end user point of view. TList version imposes more memory fragmentation (each element is in its own block) which could be convenient or not based in the amount of memory available and the current fragmentation (big blocks are not always the better solution). I take the time to peform the test suggested in previous mail, allowing the dyn array to known the amount of elements available in advance, and here are the results: Elements Record of bytes Dyn array TList --- - 100 64187 ms 1328 ms 1040961032 ms1046 ms 1040951469 ms1031 ms 10 16384Crash 5954 ms 1 655361656 ms2188 ms 1 655372312 ms2219 ms The "crash" was due there was not available 1.5 Gby available in one block. I can post the code if you like. -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Linking C object against "Pascal runtime"
Hi,
I have a C file which I want to link statically into my FreePascal application.
The C code is mostly self-contained, except for a few simple calls to the C
runtime, one of them being "_strlen".
Now "_strlen" is a simple enough function to rewrite it in Pascal, and so I
did. However, FreePascal seems unable to recognize my strlen function in
Pascal. It keeps reporting "Error: Undefined symbol: _strlen". My code looks
like this, and "_strlen" is clearly present:
{$link cfile.o}
function _strlen(s: pansichar): integer; cdecl;
begin
Result := 0;
while s^ <> #0 do
begin
Inc(Result); Inc(s);
end;
end;
Is it not possible to link C object files against an internal "Pascal runtime"?
Or if it is, how do I make it happen?
Any solutions would be greatly appreciated!
Moichos
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linking C object against "Pascal runtime"
FPC automatically does name mangling in your procedures, I guess your procedure really looks currently like: function _strlen(s: pansichar): integer; cdecl name 'MYUNIT$_STRLEN'; Or even greater, with parameter type info and stuff. I would recommend that you declare it as: function _strlen(s: pansichar): integer; cdecl name '_strlen'; -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linking C object against "Pascal runtime"
On 08 May 2010, at 21:37, moic...@gmx.de wrote: > I have a C file which I want to link statically into my FreePascal > application. The C code is mostly self-contained, except for a few simple > calls to the C runtime, one of them being "_strlen". > > Now "_strlen" is a simple enough function to rewrite it in Pascal, and so I > did. However, FreePascal seems unable to recognize my strlen function in > Pascal. It keeps reporting "Error: Undefined symbol: _strlen". My code looks > like this, and "_strlen" is clearly present: C name mangling is not the same on all systems. On several systems, if you declare a function called "strlen" in C, the assembler symbol will actually be called "_strlen". The C compiler automatically adds the "_" prefix if necessary, and so does FPC when you use the "cdecl" calling convention. So change the "_strlen" into "strlen" and try again. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linking C object against "Pascal runtime"
On 08 May 2010, at 23:09, Felipe Monteiro de Carvalho wrote: > FPC automatically does name mangling in your procedures, I guess your > procedure really looks currently like: > > function _strlen(s: pansichar): integer; cdecl name 'MYUNIT$_STRLEN'; No, it does not. cdecl always results in C name mangling. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
