Gpc

gpc@gnu.de

5400 discussions

License question...
by Orlando Llanes 05 Jun '97

05 Jun '97

Thanks for the help with the port statements! I figure that $define'ing them will save time because of no stack operations (right? :}). I was looking at the FAQ again, and saw the license, I can see that GPC can be as big as GCC, but the problem I have is that what I want with it conflicts with it's license, I want to develop computer games commercial/shareware. I will be writing my own Game Libraries, and am willing to make them free under GNU to develop commercially or for education. But what puts me in the spot is that the license in a way says I can't develop comemrcially? Are there exceptions or exclusions? See ya! Orlando Llanes

2 1

Re: Machine Code...
by PredatorZeta 05 Jun '97

05 Jun '97

According to Peter: > Function InPortW ( port: Integer ) result: ShortWord; > > begin (* InPortW *) > asm ( 'inw %%dx, %%ax' : '=a' ( result ) : 'd' ( port ) ); > end (* InPortW *); > > > Function InPortB ( port: Integer ) result: Byte; > > begin (* InPortB *) > asm ( 'inw %%dx, %%al' : '=a' ( result ) : 'd' ( port ) ); > end (* InPortB *); > > > (NOT TESTED, sorry!) > PredatorZeta, are you sure that it's `inw' in the second case, > not `inb'? Thanks Peter for your bugfixes to my procedures! I know, I'm very absent-minded in these days..."inw" it's because I cute and paste in Rhide the first proc!!! BTW, here it's occasion to explain two things (heheheh): 1)_The reserved word "result" ISN'T explained properly in the info documentation. (at least in my version!!???). It work, but with this stupid warning: Warning: return value of function not assigned I think because GPC can't consider the Asm assignment as a real assignment.... 2)_The code outputted from your proc with -O2 switch activated is: 1 pushl %ebp 2 movl %esp,%ebp 3 subl $12,%esp 4 movl %ecx,-4(%ebp) 5 movl 8(%ebp),%edx /APP 6 inb %dx, %al /NOAPP 7 movb %al,-5(%ebp) 8 movb -5(%ebp),%al | 9 leave 10 ret =8-||||| AAAAAAAARRRRGGGHHH!!!8-)) Whatta the lines 7 and 8 do?????? NOTHING!!! If I cutout these lines the code works IDeNtIcAL!! Also this cost >3< clock cycles on Pentium, for the AGI stall... > PredatorZeta, are you sure that it's `inw' in the second case, > not `inb'? Uhhmmmm....OKK, This is my fault:)))))))))))) > BTW, you can even use these as procedures in your program without loss of > speed: With full optimization `-O3', GPC will automatically inline the > above. Trust me, with these macro: {$DEFINE Inportw(port,myvar) Asm("inw %%dx, %%ax" : "=a" (myvar) : "d" (port))} {$DEFINE Inportb(port,myvar) Asm("inb %%dx, %%al" : "=a" (myvar) : "d" (port))} the code works without useless MOVs, and it's inlined with or without -O3.8-)))))) Cya... -- [<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<] | Codename: PrEdAtOr~Z; Sex: Male; Status: Free coder | * E-mail: predatorzeta(a)geocities.com * | URL: http://www.geocities.com/SiliconValley/Vista/6573 | [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]

2 1

Re: gpc-970510: source uploaded
by Maurice Lombardi 05 Jun '97

05 Jun '97

Maurice Lombardi wrote: > > OK it works fine now. > first just change the GPERF_FLAGS in config/msdos/makefile, without > touching gpc-gperf.c > It compiles but the resultant gpc-gperf.c with my gperf 2.1 is different > from the distributed made with gperf 2.5 I have then sent the following message to DJ Delorie: >> May I ask to Delorie to upgrade gperf to version 2.5 which is used in the >> alpha distribution of gpc: there do are differences between the two >> versions which cause problems when compiling this alpha version. and received the answer: > Asking won't help. Somebody should port the newer version and submit > the source patches to DJ Delorie. I did the port of Cperf 2.1a, but I > don't have time to port the new version right now. (And I'm not sure > we should port versions that weren't officially released by GNU, > anyway.) You only can answer to him if you think it is important: otherwise you will need to pay attention in the future distributions that gpc-gperf.c will always be more recent than gpc-lex.c. Thanks anyway for your work !

1 0

Re: OOP
by Peter Gerwinski 05 Jun '97

05 Jun '97

According to Frank Heckenbach: > > Look at it this way: If there's a field in the base class that not everybody > needs, there's no way for those who don't need it to remove it by deriving > a new class, so they'll have to carry something useless in their programs. True. > If, however, a field that some people need is not in the base class, they can > just derive their own base class and forget about the old base class. Sorry, but this is *not* true. I had *lots* of problems with Turbo Vision for this reason. While generalizing Turbo Vision for graphics mode (thus creating BO3), it was necessary to introduce new fields to `tView'. Since I didn't have the TV source (I didn't want to spend 600DM (~$400) for it (but finally did, you know ...): ), I had to derive successor objects from *each* for-real-use object: `tWindow', `tDialog', `tInputLine', ... it was not only bulk of work, but also very unclean Pascal. Once I had the TV source, I threw away BO3, added the necessary fields to `tView' and essentially re-wrote TV (BO4. My next project of this kind, BO5, will be completely independend of TV (... like BO2 was. I had better continued BO2 rather than trying to use TV ...)). This example (where to have fields) proves how difficult it is to design a class library for general use. It might be a good idea to introduce some initially unemployed data fields in some base objects just for future use. (Not in *the* base object, but somewhere higher in the hierarchy, where space doesn't matter so much.) > [Some small procedure ...] > > (Better declare it as inline, though...) \begin{off-topic} Or compile it with `-O3', so GPC will automatically inline it. \end{off-topic} Greetings, Peter Dr. rer. nat. [970604] Peter Gerwinski, Essen, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Machine Code...
by Peter Gerwinski 04 Jun '97

04 Jun '97

Hi! Just cleaning up a little ... According to PredatorZeta: > > Type > Byteint = __byte__ Integer; > Byte = __unsigned__ Byteint; > Shortint =__short__ Integer; > Word16 = __unsigned__ Shortint; `ByteInt', `Byte', and `ShortInt' like above are already built-in in recent (alpha) versions of GPC. `Word16' also exists but is named `ShortWord'. > Function Inportw(port : integer) : word16; > var temp : word16=0; > begin > Asm("inw %%dx, %%ax" : "=a" (temp) : "d" (port)); > Inportw:=temp; > end; > > Function Inportb(port : integer) : byte; > var temp : byte=0; > begin > Asm("inw %%dx, %%al" : "=a" (temp) : "d" (port)); > Inportb:=temp; > end; This can be abbreviated further (and indented;-): Function InPortW ( port: Integer ) result: ShortWord; begin (* InPortW *) asm ( 'inw %%dx, %%ax' : '=a' ( result ) : 'd' ( port ) ); end (* InPortW *); Function InPortB ( port: Integer ) result: Byte; begin (* InPortB *) asm ( 'inw %%dx, %%al' : '=a' ( result ) : 'd' ( port ) ); end (* InPortB *); (NOT TESTED, sorry!) PredatorZeta, are you sure that it's `inw' in the second case, not `inb'? BTW, you can even use these as procedures in your program without loss of speed: With full optimization `-O3', GPC will automatically inline the above. Hope this helps, Peter Dr. rer. nat. [970604] Peter Gerwinski, Essen, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: gpc-970510: source uploaded
by Peter Gerwinski 04 Jun '97

04 Jun '97

According to Maurice Lombardi: > > You only can answer to him if you think it is important: otherwise > you will need to pay attention in the future distributions that > gpc-gperf.c will always be more recent than gpc-lex.c. I will do the second. `gpc.gperf' does not change very often, so I don't consider it necessary to recommand everybody to get `gperf'. Greetings, Peter Dr. rer. nat. [970604] Peter Gerwinski, Essen, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Machine Code...
by PredatorZeta 04 Jun '97

04 Jun '97

Orlando Llanes <ollanes(a)accesspro.net> wrote: > My problem is that when I type "asm( 'inb %al, %dx' );" the compiler says "386 > instruction not recognized" AAAHhrrrgg!!! :)) I posted in this mailing-list the my GPC ASM documentation yesterday. SOURCE and DEST operands in At&t syntax are ALWAYS swapped!!!!!! >I tried using an INLINE statement, that didn't work either, Yes, it don't work, not as in BP, however. > I even tried "asm( '$EC' );" which is the machine code > equivalent, still nothing, then I tried "asm( 'db $EC' ); The GPC equivalent of the BP Inline($EC); --->>>>> is ------>>>> Asm(" .byte 0xEC"); > I understand that GPC was meant to be cross platform, but I need > port access. I also know that I could link it externally, but I don't want > to have to do that unless it's absolutely necessary :( Thanks in advance! Get my ASM documentation at http://www.geocities.com/SiliconValley/Vista/6573/index.html if you haven't it yet. Otherwise, inportw and inportb procedure are in attachment... > See ya! Ciao, PredatorZ. -- [<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<] | Codename: PrEdAtOr~Z; Sex: Male; Status: Free coder | * E-mail: predatorzeta(a)geocities.com * | URL: http://www.geocities.com/SiliconValley/Vista/6573 | [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]

1 0

Re: OOP
by The African Chief 04 Jun '97

04 Jun '97

On Wed, 4 Jun 1997 13:07:57 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: >> >We're talking about a class library for widespread use, aren't we? >> >Imagine if everybody changed the base objects: No units of different sources >> >would fit together! >> >> No, you shouldn't - IF you are going to distribute your own >> sources for public consumption. If it is just for your own >> private use, I don't see the problem. > >A problem is there if you might want to use someone else's sources based on >the original library some time. True enough. >> >The OOP way to do this is: if something doesn't suit you, derive a new class, >> >and apply all modifications you want to the new class. >> >> That is still based on the assumption that you are happy to live with >> the original class as it was. What if you are not? It is like having a bad >> ancestor with bad genes or no good genes at all. I can see the point >> in the "pure OOP" theory, and I would do that if I was presented with a >> ready-made ancestor (you can't choose your ancestors, or the genes >> which you will inherit or not inherit from them). However, if I were the >> one to decide what that ancestor should be, I would still do it exactly >> like I did it. > >That's exactly my point. That's why I'm so picky about the base classes. >Look at it this way: If there's a field in the base class that not everybody >needs, there's no way for those who don't need it to remove it by deriving >a new class, so they'll have to carry something useless in their programs. Perhaps useless for some purposes - but useful for others. We are all used to data structures with "reserved" members (e.g., the TFileRec and TSearchRec records). The fact is that although "Handle" _may_ be useless for non-windowed objects "SelfID" is quite useful for all sorts of objects - simply because of its function in locating object instances. >If, however, a field that some people need is not in the base class, they can >just derive their own base class and forget about the old base class. > >This is from the point of view that there are common base classes (though >not enforced by the compiler, this will happen if many people use a library >and write new code for it). > >> I may have other uses for it in TObject - and now I do. AFAICS when you >> dispose of an object and/or call its destructor, GPC does not set it to NIL. > >By "it", you mean a pointer to it, do you? Yes. >> This has caused me a number of problems in trying to ascertain which >> instance has been destroyed (you can't just check by finding if its value >> is NIL). A temporary hack (until I can see a better alternative) has been >> to set the handle to a specific negative number in the destructor (the >> handle should normally never be negative). > >Doesn't work reliably. Once the object has been disposed of, its memory can >be overwritte by other things, so in the place where the handle was there >can be a positive number. True - but that would not be the only check. >Why don't you just manually set the pointer to NIL? You can use this >generalized procedure: > >procedure Destroy(var p:PObject); >begin > Dispose(p,Done); > p:=NIL >end; I did write a similar procedure - basically, it didn't work. The test : "If (p<>Nil)" still returned TRUE. I am still looking into this. >(Better declare it as inline, though...) Meaning? I hope you are not referring to Turbo's ghastly inline code which has to be commented with ASM statements! >> Big problem with pointers. Try passing a pObject or whatever >> from one application to another, with a call to PostMessage >> (I haven't, but I personally wouldn't try it). > >Hmmm... -- and what would the other application do with an ID? As far as >you've shown so far, you use the IDs to find a pointer, and then? And then, do whatever the message tells you to do with it. >> They don't need to reside in any kind of shared memory. I have >> passed messages from Win32 applications and DLLs to other >> Win32 applications (and even Win16 applications, and a CMD.EXE >> command prompt), all of which live in separate address spaces, >> with a call to PostMessage. > >So the different apps can't address each other's objects, can they? No. >Then what do they do with the IDs (I really don't understand)? Do they just >store them and send them back in some other messages? Yes - without using the ghastly DDE stuff. >They could do the same with pointers (even if they can't address what the >pointers point to).Or what is it? Theoretically, it is possible, but it is fraught. First of all, message parameters are passed as Words or Longints. You can typecast : Longint ( @PMyObject ) or Longint ( PMyObject ) to send the address in a message. When you get it back, it will still be in a type-casted Longint. How do you then do you convert this to an object instance; p := pObject ( aLong ) or p := pObject ( @aLong ) which would you use? then you would do; If p <> Nil then ... - apart from the fact that I have no idea what all these type casts would be doing to what I am sending and receiving (like I said, I haven't tried sending an object's address, and I have no inclination to try it), personally, I would prefer to send a message parameter as; PMyObject^.SelfID and when I receive a message back with the SelfID in "aLong", to do; p := InstanceFromSelfID ( aLong ) then I would do; If p <> Nil then ... >> >Yes, you're right. With Load being a constructor, and explicitly declaring >> >the StreamRecs, this works. BTW: Does TObject need a Load constructor at all? >> >> Probably. I seem to remember needing it there to implement my Streams. > >I don't know. I just know Borland's TObject doesn't have Load. No. But they did a lot of things in ASM to get round some problems. >> >I suppose you're looping through an array of IDs, right? >> >> No. You are dealing with data held in a list object (a TObject >> descendant). Have you actually looked at OBJECTS.PAS? > >Parts of it (I don't like reading uncommented asm code very much...)-: No - I was referring to my own OBJECTS.PAS in BPCOMPAT. >> >What do you mean by "allocate"? Do you have a global "collection" of all >> >"active" (=existing?) objects, with their addresses and IDs? >> >> An object declared in the implementation section, with a linked list >> of existing object instances. > >Perhaps you need them. I do! >I don't think one always needs such a "big brother", >therefore the ID should not be part of *all* objects. Perhaps not - but I personally think that one would need it frequently. Once you have it, you wonder how you ever did without it. And what happens when you do need it? What if you suddenly discovered the need to use it in connection with a collection, and a control, and a Stream and a file object? You would need to create a common ancestor for all of them, and then go back and change all your sources to derive from this common ancestor - or you would put it in TObject so as to avoid all that, and break all your code in the process. >> You could walk the list, yes. However, not everybody is comfortable >> with linked lists - but AFAIK, everybody can write a "for loop". > >(* Everybody? -- Just look at c.l.p.b. ... ;-( *) Ok - you are right ;) - but "for loops" are still easier for some people than linked lists. >I think, everybody who's serious about OOP knows linked lists, don't they? I knew *about* linked lists for about 7 years but did not know how to implement them. I only gained this knowledge in the past 2 years - and I have been doing Borland-style OOP since 1989. I know some very experienced database programmers who have now moved to Delphi 2 (from VB, FoxPro, Access and Sage Sovereign), who write multi-user and mission-critical database and accounting systems, who do not have (and probably will never have) a clue about linked lists. But they can write "for loops". >> >> So, I could really just do something randomly like this; >> >> >> >> p := InstanceFromSelfID ( 5 ); >> > >> >This means "give me a pointer to the object with ID 5", or what? >> >> Yes - when you don't even know whether such an object exists. >> >> >With the changes above, you would already have the pointer instead of the >> >ID 5, so this function call would even get superfluous. >> >> You would only have the pointer by walking the list and incrementing a >> counter until it got to 5, and then retrieving whatever was being pointed >> to when you get to 5. Doesn't save you any coding at all. > >What I meant, where do you get the "5" from? I said it was random. I am not saying that anyone would want to do something random like that - but that it could be done. And if you are receiving this number from somewhere else (e.g., another app) then you would need to do something like that. >It's not hardcoded in any program, is it? AFAICS, you got this number either >as an ID of a specific object (of which you could just as well have got the >address in the first place), Yes, you could - and here you wouldn't need the ID. >or by looping through all existing objects. Looping through all objects with positive IDs - until you find the one you are looking for. >Well, I see two problems addressed by you: > >- to check if a given ID is valid, and if so, give a pointer to the object. > This is almost trivial with pointers as "IDs": just check if the pointer > is in the list, if so return it, otherwise return NIL. If you already have the pointer, there is no need to do any of this. So, I think you are still missing the point. Your solution involves already having the pointer - but what if you don't already have it? This is what the SelfID retrieves for you. Assuming you receive a message from another application saying "tell the object with ID number 437 to read some data from the serial port" - how would you proceed using your solution? >- to do something for all objects. > Just walk through the list. BTW, it's more efficient than for-looping > through all IDs, because you don't hit the "dead" IDs. Furthermore, it's > much more efficient (O(n) instead of O(n^2)) because you don't have to > look up every ID by searching through the list! Like I said, destroying an object does not set the pointer thereto to NIL. You would still come up with cases where "If p <> NIL" would return TRUE, and yet, the object does not exist. >(Apart from this discussion, a simple linked lists is quite an inefficient >thing for this use (regardless whether with numeric IDs or pointers) -- as >soon as the total number of objects gets big, searching the list gets slow >-- other structures to be considered include trees and hash tables.) True. But I am not sure how far this is significant. I once wrote a test program for ChiefAPP (an installation program) with literally hundreds of active objects (buttons, labels, collections, gauges, dialogs, etc), with all sorts of messages going back and forth. On a 486DX2/50, it ran like the wind. If I had 500,000 active objects, then some slowdown might show up - but I doubt that it would be significant. How many instructions are these CPUs supposed to be able to handle per second? However, in order not to be complacent, perhaps you could work on the OBJECTS unit in BPCOMPAT to change the linked list therein to a more efficient structure? Like I said, I have done my best with it. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.50 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: OOP
by Frank Heckenbach 04 Jun '97

04 Jun '97

The African Chief wrote: > >We're talking about a class library for widespread use, aren't we? > >Imagine if everybody changed the base objects: No units of different sources > >would fit together! > > No, you shouldn't - IF you are going to distribute your own > sources for public consumption. If it is just for your own > private use, I don't see the problem. A problem is there if you might want to use someone else's sources based on the original library some time. Otherwise, you're right. > >The OOP way to do this is: if something doesn't suit you, derive a new class, > >and apply all modifications you want to the new class. > > That is still based on the assumption that you are happy to live with > the original class as it was. What if you are not? It is like having a bad > ancestor with bad genes or no good genes at all. I can see the point > in the "pure OOP" theory, and I would do that if I was presented with a > ready-made ancestor (you can't choose your ancestors, or the genes > which you will inherit or not inherit from them). However, if I were the > one to decide what that ancestor should be, I would still do it exactly > like I did it. That's exactly my point. That's why I'm so picky about the base classes. Look at it this way: If there's a field in the base class that not everybody needs, there's no way for those who don't need it to remove it by deriving a new class, so they'll have to carry something useless in their programs. If, however, a field that some people need is not in the base class, they can just derive their own base class and forget about the old base class. This is from the point of view that there are common base classes (though not enforced by the compiler, this will happen if many people use a library and write new code for it). > I may have other uses for it in TObject - and now I do. AFAICS when you > dispose of an object and/or call its destructor, GPC does not set it to NIL. By "it", you mean a pointer to it, do you? > This has caused me a number of problems in trying to ascertain which > instance has been destroyed (you can't just check by finding if its value > is NIL). A temporary hack (until I can see a better alternative) has been > to set the handle to a specific negative number in the destructor (the > handle should normally never be negative). Doesn't work reliably. Once the object has been disposed of, its memory can be overwritte by other things, so in the place where the handle was there can be a positive number. Why don't you just manually set the pointer to NIL? You can use this generalized procedure: procedure Destroy(var p:PObject); begin Dispose(p,Done); p:=NIL end; (Better declare it as inline, though...) > >So the ID can be a pointer! Then InstanceFromSelfID would be a simple > >lookup in an array (or whatever structure is used to hold the IDs). > > It is not an array. Even if it were, you are still missing the point. The point > is that you can locate that pointer even if you didn't know whether the object > instance actually exists or not. Perhaps it's the same thing Peter mentioned. See my reply ("aliasing bug"). > >> If Assigned ( p ) then begin > >> If p^.Name = 'CHIEFDIALOG' then { blah blah } > > > >better: If Typeof(p^) = Typeof(TChiefDialog) then { blah blah } > > Perhaps. > > >Removes the need for Name field, also pointer comparisons are (usually) > >faster than string comparisons. > > Can you write "TypeOf" to a file or to a Stream? No (well, you could, but I'd be rather useless). For this, there's the ObjID. You could also use the ObjID in the comparison above, but I don't see any advantages, but the disadvantage that not all classes will have an ObjID. You could also (as soon as it's implemented) use the "IS" operator, which would not only recognize TChiefDialog, but all descendants of TChiefDialog. > ChiefObject? Your choice! > Big problem with pointers. Try passing a pObject or whatever > from one application to another, with a call to PostMessage > (I haven't, but I personally wouldn't try it). Hmmm... -- and what would the other application do with an ID? As far as you've shown so far, you use the IDs to find a pointer, and then? I don't see a need for IDs here -- but even if there is, this certainly applies to a very special kind of objects, not to a general TObject. > They don't need to reside in any kind of shared memory. I have > passed messages from Win32 applications and DLLs to other > Win32 applications (and even Win16 applications, and a CMD.EXE > command prompt), all of which live in separate address spaces, > with a call to PostMessage. So the different apps can't address each other's objects, can they? Then what do they do with the IDs (I really don't understand)? Do they just store them and send them back in some other messages? They could do the same with pointers (even if they can't address what the pointers point to). Or what is it? > >Yes, you're right. With Load being a constructor, and explicitly declaring > >the StreamRecs, this works. BTW: Does TObject need a Load constructor at all? > > Probably. I seem to remember needing it there to implement my Streams. I don't know. I just know Borland's TObject doesn't have Load. OTOH, if Load is going to be virtual, it must be put in some base class (or base interface like streamable). > >I suppose you're looping through an array of IDs, right? > > No. You are dealing with data held in a list object (a TObject > descendant). Have you actually looked at OBJECTS.PAS? Parts of it (I don't like reading uncommented asm code very much...)-: Where exactly should I look (class.method)? The string "id" doesn't appear anywhere in objects.pas, and the string "handle" only for DOS file handles and EMS handles, and the only places where "list" appears are "TMemoryStream.SegList/.ChangeListSize", "TStringList" (irrelevant here) and "TItemList" -- an array of pointers(!). > >What do you mean by "allocate"? Do you have a global "collection" of all > >"active" (=existing?) objects, with their addresses and IDs? > > An object declared in the implementation section, with a linked list > of existing object instances. Perhaps you need them. I don't think one always needs such a "big brother", therefore the ID should not be part of *all* objects. > >I still don't see any problem. Can't you just remove any "ID" fields (that > >contain the ID of the object itself), and change any references to other > >obejcts' IDs into pointers to them? The "collection" above would then contain > >all the addresses of active objects, and you could easily loop through them. > > You could walk the list, yes. However, not everybody is comfortable > with linked lists - but AFAIK, everybody can write a "for loop". (* Everybody? -- Just look at c.l.p.b. ... ;-( *) I think, everybody who's serious about OOP knows linked lists, don't they? > >> So, I could really just do something randomly like this; > >> > >> p := InstanceFromSelfID ( 5 ); > > > >This means "give me a pointer to the object with ID 5", or what? > > Yes - when you don't even know whether such an object exists. > > >With the changes above, you would already have the pointer instead of the > >ID 5, so this function call would even get superfluous. > > You would only have the pointer by walking the list and incrementing a > counter until it got to 5, and then retrieving whatever was being pointed > to when you get to 5. Doesn't save you any coding at all. What I meant, where do you get the "5" from? It's not hardcoded in any program, is it? AFAICS, you got this number either as an ID of a specific object (of which you could just as well have got the address in the first place), or by looping through all existing objects. Well, I see two problems addressed by you: - to check if a given ID is valid, and if so, give a pointer to the object. This is almost trivial with pointers as "IDs": just check if the pointer is in the list, if so return it, otherwise return NIL. - to do something for all objects. Just walk through the list. BTW, it's more efficient than for-looping through all IDs, because you don't hit the "dead" IDs. Furthermore, it's much more efficient (O(n) instead of O(n^2)) because you don't have to look up every ID by searching through the list! It might be a little harder to code (and really just a little), but firstly, this could go into a standard routine, written once, and secondly, this can't seriously be a reason for "blowing up" all objects and slowing down some things (including this problem itself!). (Apart from this discussion, a simple linked lists is quite an inefficient thing for this use (regardless whether with numeric IDs or pointers) -- as soon as the total number of objects gets big, searching the list gets slow -- other structures to be considered include trees and hash tables.) > However, the mechanism > that it presents for inter and intra process communication is simple enough > to grasp, and lots of programmers know it - and, more importantly, it is the > only one that I know. So everything I do with my classlib will be influenced > by that mentality, especially since it was written solely for use with the Win16 > and Win32 APIs. I presume that CYGWIN provides these facilities as well > (which it would need to do to support the Win32 API). I also believe that the > OS/2 PM APIs provide a similar messaging system. Perhaps being too > influenced by this scheme is a handicap. However, I do not see that we can > ignore it completely. As someone who has tried to write a Windows class library > that makes no call to any other class library, my method of implementation was > what worked best for me. I cannot say that it is the only, or "the best" or "the > purest OOP" method. In fact, I was not concerned with such issues at all. > However, I took a pragmatic approach, it worked, and it worked beautifully. > Perhaps I should have done my GPC objects unit in a different way - but I doubt it. > The only reason I did it at all was because I already had much of the code written > elsewhere. I only had to amend it to compile under GPC. Like I said, BPCOMPAT.1.0 > is just a beginning. The code is now out there. These discusssions have been > interesting - and it shows that the old saying about lawyers ("two lawyers, three > opinions") is also true for programmers :-). However, if anyone is going to take > objects.pas to greater heights, it won't be me. I have already done the best > I can do. That's ok! Note that I'm not talking about the BPCompat package (actually I'm not interested in its OOP/TV part very much because I have no use for it and I don't know so much about BP's TV). I'm rather talking about designing a "good" gpc class library -- "good" in the sense that it's not aimed or mostly influenced by one specific platform, that it can be used for many different kinds of programs, and that is it "good" Pascal (I don't mean only Standard Pascal, but Pascalish things rather than quick hacks, inefficient code in important places, avoidable type casts or even assembler). -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: OOP
by Frank Heckenbach 03 Jun '97

03 Jun '97

Pierre Phaneuf wrote: > > It's even more trivial: At the moment, I artificially forbid constructors > > to be virtual. To enable them, I would just have to take out the error > > message. > > To those that were thinking about removing the Init constructor... We'd > now need an anscestor... No, sorry, Init (as used in BP) can't be virtual, because it has different parameters in different classes. The Load constructor could be virtual, but not in TObject (because not all classes can be loaded from streams). Therefore, IMHO, it should be in an interface ("streamable"). One might think about another virtual constructor, one without any parameters, to be put in TObject, if such a thing makes sense for *every* possible class (constructing a "default" object of the class). Does this seem reasonable, or could there be classes for which such a constructor wouldn't make sense? > > > as I said, I'm not sure about the IUnknown > > > bit, but I think it can be optional (just declared as an empty interface for > > > compatibility reasons). > > Oh, BTW, the IUnknown thing is like TObject, it is a "parent interface"... But what does IUnknown do actually? If it's only stuff needed by Delphi, it would be an empty interface in gpc. Of course, we could declare this for compatibility, but I don't think native gpc programs must use it. (And if the point is to have a common ancestor, it would not be of much concern for gpc, either, since we voted (more or less) against a common ancestor object type.) > This "registration number" is a very Windowy thing. I feared so... :-( > BTW, do you have a way > to avoid collision of those numbers for precompiled units that don't have > sources available? With something like TV registration, if an registration > error comes up during registration, I just register the class by hand with > a different number, and my problems are gone! If the ID will be as big as suggested (64 or 128 bits), it's possible e.g. for each programmer to get a unique ID of, say, 32 bits. Then each programmer can make sure for himself that (s)he doesn't use the same ID starting with these bits more than once. >From David's posting (28 May) I got the impression that there was a standard to generate such IDs, but even if there's not, I think we could invent some way that lets any programmer get a (most probably) unique ID. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc