AW: Re: [fpc-pascal] "Generics" Red Black Tree for fpc
Von: Mattias Gaertner Gesendet: Fr 03.04.2009 18:07 An: fpc-pascal@lists.freepascal.org; Betreff: Re: [fpc-pascal] "Generics" Red Black Tree for fpc > On Fri, 3 Apr 2009 17:16:50 +0200 > Helmut Hartl wrote: > > > Von: Mattias Gaertner > > Gesendet: Fr 03.04.2009 16:51 > > An: fpc-pascal@lists.freepascal.org; > > Betreff: Re: [fpc-pascal] "Generics" Red Black Tree for fpc > > > > > How much work do you think is it to extend it to accept duplicate > > > keys? Mattias > > > > How probable are duplicate keys in your usecase? / what is the use > > case ? It would be easy to add them as list per key node natively, > > but that would be possible with the current version too if you use a > > listtype as the storage type ... > > Of course duplicates are very unlikely, but chance is not 0. Approx 80% > of my trees must therefore support duplicates. > Using lists in the nodes would cost speed and memory (duplicates are > seldom), so I would prefer a more direct support. > > Mattias I can think of two possible ways of allowing duplicates: a) the internal node structure gets another pointer for the next duplicated storage value. (single linked list). The tree structure does not change. If duplicates are not very probable the linked list is sufficiently small to not give a huge performance penalty. The order of access would then be log(n)+k, where k ist the amount of duplicates. We have one pointer more per node. The time to scan the whole tree linear would be n*log(n). The tree semantics for a random access with duplicates would not be very clean: 1) first scan for a key 2) check if duplicates exist 3) scan the duplicate list Implementation would be easy, memory cost just one additional pointer, maybe the duplicate count in the node. b) We add 2 pointers in double linked list fashion to the tree node structure and link each node against its pred and next node. If we insert a duplicate we do it only in the list, not in the tree structure. We could then lineary scan the tree faster in the order of n, by traversing the list and rembering the last element - and in log(n) for a random access. Semantics for the access would be cleaner. 1) Search the key 2) call next until the key changes Background Info: This tree + semantic is designed for heavy multiprocessor/multithreading loads, therefor the interface must be kept as simple as possible. If you have multiple threads reading and writing concurrently on the tree, one thread(A) can search the tree by only rembering the active key, while two other thread (C,D) may delete or insert nodes. If thread A gets interupted in the scan then he can continoue with his last key value and finds the next node, making progress. If thread A would remember a pointer to the node, he could search the tree in order n (not the described n*log(n) but has to deal with deleted nodes, ABA-Problems and much headache - or the tree (as directory) must be locked as a whole while processing a linear scan. (which is practically two inefficient and slow). Which means as conclusion that the speed benefit of solution b) will vanish. A solution to the whole cause could be a STM (software transactional memory) which i currently work on - but thats far away from production quality ... So i would propose solution A) with the following semantics for a random acess - if the tree would be intended for multithreaded usage - for single threaded usage i would propose solution B). A) 1) Search the key with a function: function Find(const key:_TKey;out node:_TStore;const DuplicateIterator:TIteratorFunc):Boolean; where you pass an iteratorfunction which gets called for every extra duplicate. The multithreaded access could then be: 1) Lock the directory (r/b tree) 2) Find the key and fetch the objects and duplicates, lock them 3) unlock the tree 4) process the objects/data i hope i was somewhat clear :-) If it is of value i would implement a solution. helmut ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] "Generics" Red Black Tree for fpc
On Fri, 3 Apr 2009 17:16:50 +0200 Helmut Hartl wrote: > Von: Mattias Gaertner > Gesendet: Fr 03.04.2009 16:51 > An: fpc-pascal@lists.freepascal.org; > Betreff: Re: [fpc-pascal] "Generics" Red Black Tree for fpc > > > How much work do you think is it to extend it to accept duplicate > > keys? Mattias > > How probable are duplicate keys in your usecase? / what is the use > case ? It would be easy to add them as list per key node natively, > but that would be possible with the current version too if you use a > listtype as the storage type ... Of course duplicates are very unlikely, but chance is not 0. Approx 80% of my trees must therefore support duplicates. Using lists in the nodes would cost speed and memory (duplicates are seldom), so I would prefer a more direct support. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generating code form xmi files
We could work on it. Perhaps any one cold start a project for that. And others help. My English and my knowledge in C++ is very pour. But i help any one do it. 2009/4/3 Michael Van Canneyt > > > On Fri, 3 Apr 2009, Mattias Gärtner wrote: > > > Zitat von Michael Van Canneyt : > > > > > > > > > > > On Fri, 3 Apr 2009, Graeme Geldenhuys wrote: > > > > > > > On Thu, Apr 2, 2009 at 10:05 PM, Philippe Martinole > > > > wrote: > > > > > > > > > > xmi files (not xml) are used to save uml models : > > > > > http://en.wikipedia.org/wiki/XML_Metadata_Interchange > > > > > and I want to gererate my data structures from my uml diagrams > > > > > I would be suprised if nothing already exists > > > > > > > > I've been looking for something like this for a long time and haven't > > > > fond anything for Free Pascal / Lazarus. You can obviously use Model > > > > Maker and simply tweak the generated object pascal code to make sure > > > > they are compilable with FPC. But I believe Model Maker is quite > > > > pricey. > > > > > > Well, Umbrello (Open source, comes with KDE) can generate code from XMI > > > for various languages (C,C++,PHP, Java) except pascal. All you need to > > > do is write an output engine for pascal. > > > > > > It is on my todo list, item no. 132.458 :-) > > > > I just tested Umbrello and I got the impression it is very C++-centric - > the > > dialogs, the options, the code. For example I don't see how to setup free > > pascal properties - it seems to have only basic variables as attributes. > > Is this a shortcoming of UML in general? > > No, I don't think so; But the 'pascal' implementation is very rudimentary, > for instance there is no 'published' visibility. if you look at the > language specific options, you'll see that the pascal language has no > options yet. I would expect that one could put some pascal-specific > things there. > > I expect it'll be up to us to provide this :( > > I use umbrello extensively for the diagrams till now, > it would of course be nice to have it import/export pascal code as well. > > So, it remains on my todo list. But maybe if interest is raised enough, > someone with more time/pressing needs will do it before me :-) > > Michael. > ___ > 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: [fpc-pascal] Constructors & Destructors 101
Bart wrote: On 4/3/09, Jonas Maebe wrote: I think what is meant, is that if you create a direct subclass of TObject, there is no need to call TObject's create constructor (e.g., via "inherited create;") from your own constructors. It doesn't hurt if you do it of course, and may be good practice to account for future situations where the parent class may change. I often wondered abou that. So if i understand correctly: Say I have Type TFoo = class; private fSomeField: Integer; public constructor Create; end; then constructor TFoo.Create begin Inherited Create; fSomeField := -1; end; would in essence be equal to constructor TFoo.Create begin fSomeField := -1; end; Since TOblect.Create "does nothing". Essentially, yes. However, you may create subtle, lurking bugs if you omit that call and later refactor your code. For example, if you later change type TFoo = class to type TFoo = class(TSomeClass) and TSomeClass has some important work done in it's Create constructor. If you properly called "inherited Create;" now that important stuff will get done, just the way you want it to! So, the big lesson here is to stick to the proper structure even though you may have outside knowledge that the form you should follow is not strictly necessary in all cases. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
AW: Re: [fpc-pascal] "Generics" Red Black Tree for fpc
Von: Mattias Gaertner Gesendet: Fr 03.04.2009 16:51 An: fpc-pascal@lists.freepascal.org; Betreff: Re: [fpc-pascal] "Generics" Red Black Tree for fpc > How much work do you think is it to extend it to accept duplicate keys? > Mattias How probable are duplicate keys in your usecase? / what is the use case ? It would be easy to add them as list per key node natively, but that would be possible with the current version too if you use a listtype as the storage type ... helmut ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constructors & Destructors 101
On 03 Apr 2009, at 16:21, Bart wrote: So if i understand correctly: Say I have Type TFoo = class; private fSomeField: Integer; public constructor Create; end; then constructor TFoo.Create begin Inherited Create; fSomeField := -1; end; would in essence be equal to constructor TFoo.Create begin fSomeField := -1; end; Since TOblect.Create "does nothing". Yes. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Constructors & Destructors 101
Thanks Jonas and Leledumbo for your answers. Most of this makes sense to me now. Some minor followup questions / comments (snipped) C) Just out of curiosity, am wondering why FreeAndNil is global procedure instead of a method/destructor of TObject. ... c:=c.tsomeclass.create; c.freeandnil then freeandnil would get, as first (hidden) parameter, the self pointer. However, this self pointer is a value parameter. So it would only contain the value of "c", not its address. Hence, there is no way to set "c" to nil inside the freeandnil method (while setting the instance variable to nil is the entire reason for using freeandnil). --- And one of the features of FreeAndNil is to zero the reference BEFORE deallocating the memory which I assume would be problematic to do "inside" the instance in question. 5) Although I can't remember reading it anywhere, I've noticed from my own demo programs that the addresses of objects are initially set to nil. That is not correct. All global variables (classes/objects or not) are initialized to 0/nil, but local variables aren't (except in case of reference-counted types). Moreover, the contents of a class instance are also zeroed when creating it. --- Yes, I was only testing with global object variables. I also noticed that the contents were initially set to zero on creation but the address itself was not set to zero when destroying the object. That bewilderment was cleared up by reading the docs more closely and the answers I got here. A) ... What is it meant by: "no need to call [create] directly?" How do you invoke the constructor without calling it? I think what is meant, is that if you create a __direct subclass__ of TObject, ... -- Yes, that makes sense ..there is no need to call TObject's create constructor (e.g., via "inherited create;") from your own constructors. It doesn't hurt if you do it of course, and may be good practice to account for future situations where the parent class may change. -- As my own debugging aid to check for memory leaks, I've added a global object counter to my own create and destroy routines which keeps track of the net number of instances created/destroyed. Although you probably would not want it in final release code, that might be a situation where TObject.Create might do something. ... and ... Why is create not virtual and the destroy destructor is? Because when creating a class instance, you usually know the exact class type of that instance ... ...Conversely, many routines that free a class instance, have no idea about the exact type of that instance ... -- This is clear to me now. B) ... What is it meant by: "No other destructor should be implemented?" It means that you should not add "destructor my_peculiarly_named_destructor; virtual;" to your own classes. The reason is that TObject's free method, which is used by pretty much all code out there, is hardcoded to call "destroy". So if your destructor is named differently, a lot of existing code will not properly destroy instances of your class type. --- Maybe a compiler warning for this situation is warranted? ...and... Does it do "something" while the Create constructor doesn't? No, TObject's default destructor does not do anything either. --- I understand the semantics now. Neither does anything specific but they do "do something"; allocate and deallocate memory as an effect of the root class implementation. - ROW ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] "Generics" Red Black Tree for fpc
On Fri, 3 Apr 2009 13:08:42 +0200 Helmut Hartl wrote: > Hi all, > > due to interest i post here our generic version of a red black tree > implementation. A R/B tree is a quite fast directory datastructure > which allows o(log n) access times. > > Warning: The code compiles only under 2.2.4RC1+, below that the > compilation fails(crash). > > Further info on > http://fpcfun.firmos.at/bin/view/Freepascal/FirmOSOpenSource > > A short description with usage guidelines and a testprogram > demonstrating adding and searching 10 Million key / value pairs is > provided there too. > > The code was tested under FreeBSD (dev platform), linux and windows > and has no dependancys. > > have fun, I surely have. How much work do you think is it to extend it to accept duplicate keys? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constructors & Destructors 101
On 4/3/09, Jonas Maebe wrote: > I think what is meant, is that if you create a direct subclass of TObject, > there is no need to call TObject's create constructor (e.g., via "inherited > create;") from your own constructors. It doesn't hurt if you do it of > course, and may be good practice to account for future situations where the > parent class may change. I often wondered abou that. So if i understand correctly: Say I have Type TFoo = class; private fSomeField: Integer; public constructor Create; end; then constructor TFoo.Create begin Inherited Create; fSomeField := -1; end; would in essence be equal to constructor TFoo.Create begin fSomeField := -1; end; Since TOblect.Create "does nothing". Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constructors & Destructors 101
> C) Just out of curiosity, am wondering why FreeAndNil is global procedure > instead of a method/destructor of TObject. I am guessing it is > for compatibility with Delphi which may or may not have a reason? A method could not act the way FreeAndNil works (zeroing a local pointer variable). It could be a static/class method, but this would just add noise to the code. BTW FreeAndNil can only on TObject and descendants. -Flávio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] "Generics" Red Black Tree for fpc
Hi all, due to interest i post here our generic version of a red black tree implementation. A R/B tree is a quite fast directory datastructure which allows o(log n) access times. Warning: The code compiles only under 2.2.4RC1+, below that the compilation fails(crash). Further info on http://fpcfun.firmos.at/bin/view/Freepascal/FirmOSOpenSource A short description with usage guidelines and a testprogram demonstrating adding and searching 10 Million key / value pairs is provided there too. The code was tested under FreeBSD (dev platform), linux and windows and has no dependancys. have fun, helmut ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generating code form xmi files
On Fri, 3 Apr 2009, Mattias Gärtner wrote: > Zitat von Michael Van Canneyt : > > > > > > > On Fri, 3 Apr 2009, Graeme Geldenhuys wrote: > > > > > On Thu, Apr 2, 2009 at 10:05 PM, Philippe Martinole > > > wrote: > > > > > > > > xmi files (not xml) are used to save uml models : > > > > http://en.wikipedia.org/wiki/XML_Metadata_Interchange > > > > and I want to gererate my data structures from my uml diagrams > > > > I would be suprised if nothing already exists > > > > > > I've been looking for something like this for a long time and haven't > > > fond anything for Free Pascal / Lazarus. You can obviously use Model > > > Maker and simply tweak the generated object pascal code to make sure > > > they are compilable with FPC. But I believe Model Maker is quite > > > pricey. > > > > Well, Umbrello (Open source, comes with KDE) can generate code from XMI > > for various languages (C,C++,PHP, Java) except pascal. All you need to > > do is write an output engine for pascal. > > > > It is on my todo list, item no. 132.458 :-) > > I just tested Umbrello and I got the impression it is very C++-centric - the > dialogs, the options, the code. For example I don't see how to setup free > pascal properties - it seems to have only basic variables as attributes. > Is this a shortcoming of UML in general? No, I don't think so; But the 'pascal' implementation is very rudimentary, for instance there is no 'published' visibility. if you look at the language specific options, you'll see that the pascal language has no options yet. I would expect that one could put some pascal-specific things there. I expect it'll be up to us to provide this :( I use umbrello extensively for the diagrams till now, it would of course be nice to have it import/export pascal code as well. So, it remains on my todo list. But maybe if interest is raised enough, someone with more time/pressing needs will do it before me :-) Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Memory Size
In our previous episode, Markus Glugla said: > (very very quick) memory as a cache as soon as practicable. I would > cache streams of measurement values (single type, sample rate circa > 32KHz). The measurement program will run on diffrent machines with > diffrent RAM. Depending on the free memory the number of measurement > values or the measurement times are diffrent. The reason to know the > free memory is to decide what or how should I measure. All buffered > prints into a file are to slow and produce underruns. My idea is to >stream the measurement values into an array and write the array on > disk after the measurement. To do this I must know the memory ;-) > > Is there a other way to get the free memory size? As Jonas said you first have to define that value in a multitasking environment. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generating code form xmi files
Zitat von Michael Van Canneyt : > > > On Fri, 3 Apr 2009, Graeme Geldenhuys wrote: > > > On Thu, Apr 2, 2009 at 10:05 PM, Philippe Martinole > > wrote: > > > > > > xmi files (not xml) are used to save uml models : > > > http://en.wikipedia.org/wiki/XML_Metadata_Interchange > > > and I want to gererate my data structures from my uml diagrams > > > I would be suprised if nothing already exists > > > > I've been looking for something like this for a long time and haven't > > fond anything for Free Pascal / Lazarus. You can obviously use Model > > Maker and simply tweak the generated object pascal code to make sure > > they are compilable with FPC. But I believe Model Maker is quite > > pricey. > > Well, Umbrello (Open source, comes with KDE) can generate code from XMI > for various languages (C,C++,PHP, Java) except pascal. All you need to > do is write an output engine for pascal. > > It is on my todo list, item no. 132.458 :-) I just tested Umbrello and I got the impression it is very C++-centric - the dialogs, the options, the code. For example I don't see how to setup free pascal properties - it seems to have only basic variables as attributes. Is this a shortcoming of UML in general? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Memory Size
Hi Jonas, thank you for your answer. > On which OS? Debian 5.0 GNU/Linux (uname -r: 2.6.26-1-686) > Anyway, even if it would return non-zero values, the information would > be next to useless. The reason is that on modern OS'es, available > physical memory is dynamically divided between the disk cache and > applications, with a lower limit on the disk cache. ... > The information provided by GetFPCHeapStatus is only useful to get > statistics about the heap manager, and not to get any information > about the system you are running on. I have misunderstood this. Ok, thank you. > And what happens if you allocate some memory at the start of your program? > What would you expect memavail to report? The current amount of really "free" > memory? > Free + cache? Free + part of cache? Free + non-wired (i.e., swappable) > + part of cache? Free + non-wired + part of cache + swap space? I need the really "free" memory. I would use the maximal available free working memory (no swap or so) because I need a program-internal quick (very very quick) memory as a cache as soon as practicable. I would cache streams of measurement values (single type, sample rate circa 32KHz). The measurement program will run on diffrent machines with diffrent RAM. Depending on the free memory the number of measurement values or the measurement times are diffrent. The reason to know the free memory is to decide what or how should I measure. All buffered prints into a file are to slow and produce underruns. My idea is to stream the measurement values into an array and write the array on disk after the measurement. To do this I must know the memory ;-) Is there a other way to get the free memory size? Thanks Markus ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generating code form xmi files
On Fri, Apr 3, 2009 at 11:32 AM, Frank Peelo wrote: > >>> It is on my todo list, item no. 132.458 :-) > > >> Do you *only* have 132 todo items - lucky you ! :-) > > In /his/ locale, he writes '.' I know - my smiley face has a double meaning. 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] Generating code form xmi files
On Fri, Apr 3, 2009 at 11:12 AM, Michael Van Canneyt wrote: > > Correction. It seems to have been implemented... > I must urgently upgrade my KDE :-) Wow, the new KDE 4.x looks pretty cool, especially with the new Oxygen theme. Really wow!! I'm using Ubuntu 9.04 beta with Qt+KDE libs installed. 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] Generating code form xmi files
Graeme Geldenhuys wrote: On Fri, Apr 3, 2009 at 10:51 AM, Michael Van Canneyt wrote: ... It is on my todo list, item no. 132.458 :-) ... Do you *only* have 132 todo items - lucky you ! :-) In /his/ locale, he writes '.' In /your/ locale, i'd guess his '.' would be a ',' In /my/ local... I'll have a pint, thanks. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generating code form xmi files
On Fri, Apr 3, 2009 at 11:25 AM, Michael Van Canneyt wrote: > > Bummer. It writes old TP-Style object class definitions. Bummer. :-( Well, at least now you will have template code in umbrello to work from to implement true Object Pascal class types. ;-) 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] Generating code form xmi files
On Fri, 3 Apr 2009, Michael Van Canneyt wrote: > > > On Fri, 3 Apr 2009, Michael Van Canneyt wrote: > > > > > > > On Fri, 3 Apr 2009, Graeme Geldenhuys wrote: > > > > > On Thu, Apr 2, 2009 at 10:05 PM, Philippe Martinole > > > wrote: > > > > > > > > xmi files (not xml) are used to save uml models : > > > > http://en.wikipedia.org/wiki/XML_Metadata_Interchange > > > > and I want to gererate my data structures from my uml diagrams > > > > I would be suprised if nothing already exists > > > > > > I've been looking for something like this for a long time and haven't > > > fond anything for Free Pascal / Lazarus. You can obviously use Model > > > Maker and simply tweak the generated object pascal code to make sure > > > they are compilable with FPC. But I believe Model Maker is quite > > > pricey. > > > > Well, Umbrello (Open source, comes with KDE) can generate code from XMI > > for various languages (C,C++,PHP, Java) except pascal. All you need to > > do is write an output engine for pascal. > > Correction. It seems to have been implemented... > I must urgently upgrade my KDE :-) Bummer. It writes old TP-Style object class definitions. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generating code form xmi files
On Fri, Apr 3, 2009 at 10:51 AM, Michael Van Canneyt wrote: > > Well, Umbrello (Open source, comes with KDE) can generate code from XMI > for various languages (C,C++,PHP, Java) except pascal. All you need to > do is write an output engine for pascal. > > It is on my todo list, item no. 132.458 :-) I currently use "Dia Diagram editor" to design UML diagrams, but as far as I know it does generate any code. :-( I haven't tried Umbrello in years. I'll give that another try and see how things have improved over the last few years. Do you *only* have 132 todo items - lucky you ! :-) 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] Constructors & Destructors 101
On 03 Apr 2009, at 03:43, Richard Ward wrote:
A) The documentation says that for the create constructor:
(quote}
Description: Create creates a new instance of TObject. Currently it
does nothing. It is also not virtual, so there is in principle no
need to call it directly.
{unquote}
What is it meant by: "no need to call [create] directly?" How do
you invoke the constructor without calling it?
I think what is meant, is that if you create a direct subclass of
TObject, there is no need to call TObject's create constructor (e.g.,
via "inherited create;") from your own constructors. It doesn't hurt
if you do it of course, and may be good practice to account for future
situations where the parent class may change.
... and ... Why is create not virtual and the destroy destructor is?
Because when creating a class instance, you usually know the exact
class type of that instance (e.g., TObject.create -> you know that the
created instance type will be of the type TObject). This only changes
if you use class reference types, but if you use those you can still
declare your own virtual constructors.
Conversely, many routines that free a class instance, have no idea
about the exact type of that instance (such as FreeAndNil: all it
knows is that the instance inherits from TObject). So to make sure
that all resources allocated by those class types are properly freed,
the destructor almost has to be virtual (since otherwise, only
TObject's dummy destructor would be called by, e.g., FreeAndNil).
B) The documentation says that for the destroy destructor:
(quote}
Description: Destroy is the destructor of TObject. It will clean up
the memory assigned to the instance. Descendent classes should
override destroy if they want to do additional clean-up. No other
destructor should be implemented.
{unquote}
What is it meant by: "No other destructor should be implemented?"
It means that you should not add "destructor
my_peculiarly_named_destructor; virtual;" to your own classes. The
reason is that TObject's free method, which is used by pretty much all
code out there, is hardcoded to call "destroy". So if your destructor
is named differently, a lot of existing code will not properly destroy
instances of your class type.
...and... Does it do "something" while the Create constructor
doesn't?
No, TObject's default destructor does not do anything either.
If you had two different create constructors (for whatever reason),
might you not also need two different destroy destructors?
No, the default destructor should always free all resources,
regardless of how the class instance was created. Otherwise, it would
also make your code more complex, because throughout the code you
would have to track how the instance was created, so that in the end
you could call the correct destructor.
What problems might you get into if you did?
See above.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generating code form xmi files
On Fri, 3 Apr 2009, Michael Van Canneyt wrote: > > > On Fri, 3 Apr 2009, Graeme Geldenhuys wrote: > > > On Thu, Apr 2, 2009 at 10:05 PM, Philippe Martinole > > wrote: > > > > > > xmi files (not xml) are used to save uml models : > > > http://en.wikipedia.org/wiki/XML_Metadata_Interchange > > > and I want to gererate my data structures from my uml diagrams > > > I would be suprised if nothing already exists > > > > I've been looking for something like this for a long time and haven't > > fond anything for Free Pascal / Lazarus. You can obviously use Model > > Maker and simply tweak the generated object pascal code to make sure > > they are compilable with FPC. But I believe Model Maker is quite > > pricey. > > Well, Umbrello (Open source, comes with KDE) can generate code from XMI > for various languages (C,C++,PHP, Java) except pascal. All you need to > do is write an output engine for pascal. Correction. It seems to have been implemented... I must urgently upgrade my KDE :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constructors & Destructors 101
On 03 Apr 2009, at 03:43, Richard Ward wrote: 5) Although I can't remember reading it anywhere, I've noticed from my own demo programs that the addresses of objects are initially set to nil. That is not correct. All global variables (classes/objects or not) are initialized to 0/nil, but local variables aren't (except in case of reference-counted types). Moreover, the contents of a class instance are also zeroed when creating it. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constructors & Destructors 101
On 03 Apr 2009, at 03:43, Richard Ward wrote: C) Just out of curiosity, am wondering why FreeAndNil is global procedure instead of a method/destructor of TObject. If you have: var c: tsomeclass; begin c:=c.tsomeclass.create; c.freeandnil end; then freeandnil would get, as first (hidden) parameter, the self pointer. However, this self pointer is a value parameter. So it would only contain the value of "c", not its address. Hence, there is no way to set "c" to nil inside the freeandnil method (while setting the instance variable to nil is the entire reason for using freeandnil). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constructors & Destructors 101
> What is it meant by: "no need to call [create] directly?" How do you > invoke the constructor without calling it? ... and ... Why is create > not virtual and the destroy destructor is? Often in other OOP language, you need to call parent constructor before doing anything else. In OP case, you don't since it doesn't do anything. Create isn't virtual because, as stated before, it doesn't do anything therefore no relation with descendant constructor(s) needed. Destroy is because it does "soemthing" (read below). > What is it meant by: "No other destructor should be > implemented?" ...and... Does it do "something" while the Create > constructor doesn't? No other destructor should be implemented if you don't need to do any additional cleanup. It does "something", that is freeing memory assigned for the instance while create doesn't do anything. > If you had two different create constructors (for whatever reason), > might you not also need two different destroy destructors? What > problems might you get into if you did? Only if it needs two different way to cleanup. No problems if you did, I often have overloaded constructors in classes I made (which of course only calls the one with most arguments). > Just out of curiosity, am wondering why FreeAndNil is global > procedure instead of a method/destructor of TObject. I am guessing > it is for compatibility with Delphi which may or may not have a reason? It is indeed for Delphi compatibility. Other possible reason: It can be used by non-class types (i.e. Pointers) that do heap allocation. -- View this message in context: http://www.nabble.com/Constructors---Destructors-101-tp22860474p22864567.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generating code form xmi files
On Fri, 3 Apr 2009, Graeme Geldenhuys wrote: > On Thu, Apr 2, 2009 at 10:05 PM, Philippe Martinole > wrote: > > > > xmi files (not xml) are used to save uml models : > > http://en.wikipedia.org/wiki/XML_Metadata_Interchange > > and I want to gererate my data structures from my uml diagrams > > I would be suprised if nothing already exists > > I've been looking for something like this for a long time and haven't > fond anything for Free Pascal / Lazarus. You can obviously use Model > Maker and simply tweak the generated object pascal code to make sure > they are compilable with FPC. But I believe Model Maker is quite > pricey. Well, Umbrello (Open source, comes with KDE) can generate code from XMI for various languages (C,C++,PHP, Java) except pascal. All you need to do is write an output engine for pascal. It is on my todo list, item no. 132.458 :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generating code form xmi files
On Thu, Apr 2, 2009 at 10:05 PM, Philippe Martinole wrote: > > xmi files (not xml) are used to save uml models : > http://en.wikipedia.org/wiki/XML_Metadata_Interchange > and I want to gererate my data structures from my uml diagrams > I would be suprised if nothing already exists I've been looking for something like this for a long time and haven't fond anything for Free Pascal / Lazarus. You can obviously use Model Maker and simply tweak the generated object pascal code to make sure they are compilable with FPC. But I believe Model Maker is quite pricey. 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] Generating code form xmi files
Found some things on the net about Delphi and XMI, wouldn't be hard to create FPC equivalent. Something named Bold from BoldSoft (or ECO or whatever). -- View this message in context: http://www.nabble.com/Generating-code-form-xmi-files-tp22848439p22864324.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Memory Size
On 03 Apr 2009, at 02:34, Markus Glugla wrote: I need the available memory (heap). At that time the functions maxavail or memavail did this. I read that I should use GetFPCHeapStatus and other function currently. This functions produce allways zero!! What can I do? What is wrong? I use fpc version 2.2.0 [2008/05/27] for i386. On which OS? And what happens if you allocate some memory at the start of your program? Anyway, even if it would return non-zero values, the information would be next to useless. The reason is that on modern OS'es, available physical memory is dynamically divided between the disk cache and applications, with a lower limit on the disk cache. What would you expect memavail to report? The current amount of really "free" memory? Free + cache? Free + part of cache? Free + non-wired (i.e., swappable) + part of cache? Free + non-wired + part of cache + swap space? The information provided by GetFPCHeapStatus is only useful to get statistics about the heap manager, and not to get any information about the system you are running on. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
