Gpc June 1997

gpc@gnu.de

25 participants
172 discussions

Re: OOP
by Peter Gerwinski 03 Jun '97

03 Jun '97

According to Pierre Phaneuf: > > According to myself (Peter Gerwinski): > > > Okay for ordinal types, sets and pointers, not sure about Reals. > > Strings initialized to zero this way are BROKEN because they get > > a capacity of zero which makes them useless. :-( That's one reason > > why I would like to have `ShortString's in GPC.) > > Ok, right, so FillChar() is a BAD idea... Ok! :-) ... except if you know exactly that no implicitly initialized types - at the moment, these are File and Schema (including String) types - are present in the object. Since they don't belong there anyway (pointers to Strings are better than Strings here), `FillChar' can still be useful (while dangerous - which it is always). At least a `BPcompat Objects' Unit *must* have this FillChar. :-| Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, 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: Portability questions (Arrays)
by Peter Gerwinski 03 Jun '97

03 Jun '97

According to Frank Heckenbach: > According to myself (Peter Gerwinski): > > It might be necessary at the moment to `inc ( p, SizeOf ( p^ ) )'. If so, > > it's a bug which I should fix. > Yes, indeed, this bug is there! Okay. I am fixing it ... fixed. :-), Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, 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: Procedural params & pointers to procs
by Peter Gerwinski 03 Jun '97

03 Jun '97

According to YUKSEL TURAN: > > I wanted to use a C library to use Motif with my pascal program.To do > this, I had to pass some callback functions to the C part.I tried pointers > but it didn't work. So did procedural parameters. Normally, both should work. What did you try exactly? Please send some example code, and cite the documentation how the C library wants the callback function to look like. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, 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

StOp GrInNiNg AnD dRoP yOuR lInNeN...
by PredatorZeta 03 Jun '97

03 Jun '97

Hi All!! Finally, I finished to write the GPC Asm documentation. It's quite complete, but still far from perfection... Mainly because my English isn't good enough, and the things to say are very complex... (*Any help is appreciate*) By the way, get this in attachment. Also, both English and original Italian version is available at my site: http://www.geocities.com/SiliconValley/Vista/6573/index.html Check it out... There is more things to come... Greetz, PredatorZeta. -- [<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<] | Codename: PrEdAtOr~Z; Sex: Male; Status: Free coder | * E-mail: predatorzeta(a)geocities.com * | URL: http://www.geocities.com/SiliconValley/Vista/6573 | [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]

1 0

Procedural params & pointers to procs
by e1097963＠ceng.metu.edu.tr 03 Jun '97

03 Jun '97

I wanted to use a C library to use Motif with my pascal program.To do this, I had to pass some callback functions to the C part.I tried pointers but it didn't work. So did procedural parameters. How can it be done??? -Turan Y�ksel(e1097963(a)ceng.metu.edu.tr)

1 0

Re: OOP
by The African Chief 03 Jun '97

03 Jun '97

On Sat, 31 May 1997 22:02:45 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: [...] >The African Chief wrote: > >> Nothing stopping you from having a different name for your handle. Also, >> that is one reason for having the source code. You can change anything >> that doesn't suit you. > >No, no, no! (This is, you can, but you really shouldn't!) > >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. >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. >> Apart from that, in other places, I would declare the >> handle as a THandle or HWnd - the meaning of which varies depending >> on the platform. In Win16 it is a Word. In Win32 it is a long integer (which >> is the same as an integer in GPC). > >So don't declare it at all in TObject, but declare it where necessary with >the appropriate type. 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. 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). > >> You wouldn't. And that is the crux of the matter. In CHIEFAPP define a >> GetObjectCount function which returns the number of currently active >> objects. I can loop through these and do any number of things with >> the information - here is a trivial example; >> >> for i := 1 to GetObjectCount do begin >> p := InstanceFromSelfID ( i ); > >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. >> 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? > >> else If p^.Name = 'CHIEFCONTROL' then {blah blah} > >Or better yet (depending on the situation): declare a virtual method in a >common ancestor of ChiefDialog and ChiefControl (or an interface implemented >by both of them), and just call this method without any if...then's. ChiefObject? > >> > And what kind of things would you do with an unique integer ID? >> >> Inter-process communication and message passing for one. > >No problem with pointers! 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). >(Assuming the objects reside in some kind of shared >memory, but otherwise an integer ID would be quite useless as well.) 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. >> Actually, the Load constructor in TObject does nothing at all. > >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. >> SelfID can be accessed at random - e.g., through a loop. You can't >> do that with addresses. > >Why not? See below. > >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? I wouldn't want to be explaining its implementation here. > You can loop through an array of pointers as well. Of course. > >> >Where do you get the SelfIDs from? Perhaps a list of IDs stored in a parent >> >object? You could put the addresses there instead, couldn't you? >> >> There is a local instance in the OBJECTS unit which allocates an ID >> each time INIT or CREATE is called. There is a function : "InstanceFromSelfID" >> which returns a pObject for any given SelfID or NIL if there isn't any active >> object with that SelfID. > >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. >(Side note: I don't think that's a good idea. In OOP, there's hardly a need >for global data. If this collection is needed at all, it might be better put >into a "parent object".) > >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". >> 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. [...] >> A lot of that one was implemented from the perspective of >> the Windows API and communications between all sorts of things. It >> will take too much time to explain it here. > >I think Windoze is a bad example! It does pretty much anything with numerical >handles, but this is not how it should be (IMHO) in a typed language >as Pascal! Windows is probably a bad example - I don't know. 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. So, guys, please take it on! When Pierre finishes his work on TStream, we will release BPCOMPAT.1.0.1 - then others can take it further! >Pierre, I guees people are starting to think we're the same person writing >from two different accounts... ;-) I was beginning to wonder ! ;-)= Now, back to Law ... 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: Portability questions (Arrays)
by Frank Heckenbach 03 Jun '97

03 Jun '97

Peter Gerwinski wrote: > It might be necessary at the moment to `inc ( p, SizeOf ( p^ ) )'. If so, > it's a bug which I should fix. Yes, indeed, this bug is there! -- 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

OOP
by Peter Gerwinski 03 Jun '97

03 Jun '97

According to Frank Heckenbach: > > Peter, what about making virtual constructors soon? Should be relatively > easy (I hope), just "combining" the properties of constructors and virtual > methods? ;-) 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. The only problem with this: As I wrote, I am initializing the object *outside* the constructor's body. If I enable virtual constructors, this must not change any more. > What can be assumed about data fields after FillChar'ing them with 0? > I suppose, for all ordinary types, one can assume the value with "ord 0", > right? For real numbers, probably nothing can be assumed!? What about sets, > can [] be assumed? Pointers=NIL? ... Okay for ordinal types, sets and pointers, not sure about Reals. Strings initialized to zero this way are BROKEN because they get a capacity of zero which makes them useless. :-( That's one reason why I would like to have `ShortString's in GPC.) > ... and if it doesn't add misfeatures to other people, or the misfeatures > can be turned off completely, as with: > > > `--store-object-names', and switched ON in Delphi compatibility mode. > > ... and OFF otherwise! Of course! That's what I meant. :-) > I'm not sure if this notion really helps. Doing it your way, the compiler > has to distinguish between regular object types and interfaces. And I think > the code gets clearer if interfaces are clearly recognizable as such. > I don't see an advantage of your way: interfaces can't be instantiated, > anyway (since they're abstract), and a (regular) object type that should be > "inherited" form an interface, can simple implement this interface and > inherit from no type. Internally, objects are ordinary records anyway, so this makes no difference in hacking GPC - except that if I introduce an `interface' type I have to remember that something *is* an interface for no other purpose than outputting error messages. In this sense, I would prefer not to introduce interfaces as another data type but to allow MI for some special cases which I would have to check anyway. (See below for a relativation of this.) However, the above was not meant as a suggestion how to implement interfaces into GPC. It was just my attempt to understand what they are. > > [...] > > Correct. :-) (-: Great! It seems that I have got it! This increases the chance that I will be able to implement all this into GPC. :-) > (Of course, there can be conflicting method identifiers with interfaces that > are implemented, but these should simple generate "duplicate identifier" > errors.) (Agreed.) > As I said above, I'd vote for the second idea ("interface" is a keyword > anyway). AFAICS, the Delphi syntax as shown in the example by David looks > like we could adopt most of it -- 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). Agreed. If a language dialect already exists which (i) supports what we want and (ii) does it in a clean way, we should adopt it rather than inventing a new method. > Also, I think Delphi's syntax > > IWhatever = interface(...) [ID]; > > looks like a convenient way to declare the ObjID, also for regular object > types. > > To sum up (again) what I now think about ObjIDs: > > - ObjID (or whatever it will be called) is an object constant of every > object type and interface type. > > - Its type is a 64/128 bit integer. Really? In David's example it's a string constant! const SIID_IActiveScriptSiteWindow = '{D10F6761-83E9-11cf-8F20-00805F2CD064}'; type IActiveScriptSiteWindow = interface(IUnknown) [SIID_IActiveScriptSiteWindow] > [...] > > This removes all needs for class registration, and perhaps solves some > problems with interfaces. I think I like that! I agree, *and* having that we could claim more compatibility to Delphi thus making GPC more attractive for a lot of possible users. > > (* Hmm ... the above rules for "careful use of MI" could be useful for *) > > (* C++ programmers ... perhaps we should tell them? :*) > > Hmm ... I think I know some more rules for "careful use of C[++]". Should > we tell them? Would they listen to us? Would they laugh at us? ... Who knows ... > > > AFAICS, the only thing that really makes problems are variables (or > > > parameters) of interface types. > > > > What's the problem? An instance of an interface would be an empty object, > > containing nothing besides the VMT pointer. > > No! There aren't any instances of interfaces! Only if we explicitly forbid them. There is no technical reason why they shouldn't be instantiated. (And there is no practical reason why they should be, so it's safe to forbid it.;) > A variable of a pointer-to-an-interface type must point ot the actual object > (which can be of any type that implements that interface), and (somehow) give > the information where in this type's VMT the methods of that interface are > located. Then the interface must appear as an additional VMT field either in each instance of the object or in its VMT. In the first case, the assignment PointerToInterface:= PointerToObject; would add some number to the value of `PointerToObject', so `PointerToInterface' will point to the VMT of the interface, not that of the object. In the second case, the same assignment would implicitly dereference `PointerToObject', look up the VMT of the interface within the VMT of the object and let `PointerToInterface' point to that ... ah - no! This would not work, because then PointerToInterface^.SomeMethod; would have no chance to locate the implicit `Self' parameter. Okay, so forget about the second idea above; each object gets an additional VMT field for each interface it inherits. (Even then I am not sure that the above mechanism will work in all cases ... :-/ ) > > Do you mean: If an object implements an interface (in Java sense) it must > > always be accessed through a pointer? If so, why? > > No, if type T implements interface I, there can be a variable V of type T, > no problem. But V can't be of type I (since interfaces can't be > instantiated). You can, however, declare a variable P of type ^I and assign > @V to P (since V has all the properties that I demands). > > This is no special rule, it follows from the fact that interfaces can't be > instantiated. The same holds for abstract object types. Assuming TObject is > abstract, there can't be a variable of type TObject, but there can be > variables of type PObject, and there can be VAR parameters of type TObject. Ah - now I understand. :-) I tend to believe now that the above mechanism (assigning the address of an additional VMT field to `PointerToInterface') can work ... What about this: Instead of an additional VMT field, the interface is represented in each instance of the object as an integer field which holds the offset of itself inside the object: Type MyObj = object ( MyInterface ) (* No "primary ancestor" *) foo, bar: Integer; end (* MyObj *); is represented as [vmt field] [interface offset] [foo] [bar] byte# 0 4 8 12 value @vmt_MyObj 4 foo bar / \ / \ `PointerToObject' \ is pointing here. `PointerToInterface' is pointing here and can look up the address of the whole object by substracting the integer value pointed to. Now, how to call a virtual method of the interface? The following steps are needed to perform the call "PointerToInterface^.MyMethod" (each step corresponds essentially to one instruction on a CISC processor like the iX86 - or to one "tree node" passed from the GPC front-end to the GNU compiler's back-end): - Dereference `PointerToInterface' and get one integer. - Substract the integer from the pointer and get the address of the object. - Pass the new pointer as the `Self' parameter. - Dereference the new pointer and get the address of the VMT. - Find the address of the VMT of the interface in the VMT of the object at an offset which is derived from the integer we got in the first step. - Find the address of the virtual method at a fixed place in the VMT of the interface, and do the call. In contrast, the following steps are needed to call an "ordinary" virtual method "PointerToObject^.MyMethod": - Dereference `PointerToObject' and get the address of the VMT. - Pass `PointerToObject' as the `Self' parameter. - Find the address of the virtual method at a fixed place in the VMT, and do the call. This implies: - Calling a virtual method inherited through an interface roughly takes twice the time of calling an "ordinary" virtual method, but it's still O(1) (no real search required). - Each instance of each object gets one additional integer field for each interface the object inherits from. - Each VMT gets additional pointer fields pointing to the VMTs of the interfaces the object inherits from. - Pointers to interfaces have the same format as all other pointers, but they don't point to the beginning of the object but to an integer field inside the object. An explicit pointer conversion from "pointer to object" to "pointer to interface" does actually change the value of the pointer. > > > - A "pointer" to an interface variable consists of two parts: the actual > > > pointer to the variable, and the VMT offset of the first method (or, > > > alternatively, directly the adress of the first method in the VMT). > > > > > > Disadvantage: The pointer gets twice as big. The difference must be > > > considered when assigning it to another pointer (this could be an untyped > > > pointer or a pointer of one of the "parent" interfaces - in the latter > > > case the VMT offset has to be adjusted). > > > > I'm afraid we can forget about this for that reason. > > Why? Is there a rule carved in stone that a pointer must consist only of a > memory address? Yes. Here's the stone (info -f standards -n Portability): You can assume that all pointers have the same format, regardless of the type they point to, and that this is really an integer. There are some weird machines where this isn't true, but they aren't important; don't waste time catering to them. Besides, eventually we will put function prototypes into all GNU programs, and that will probably make your program work even on weird machines. This means that we mustn't introduce another format for pointers - and that we can savely assume that you can cast a pointer to an integer (see my mail about 8-byte pointers on the DEC Alpha ... @#*!). (* BTW, they also say: As for systems that are not like Unix, such as MSDOS, Windows, the Macintosh, VMS, and MVS, supporting them is usually so much work that it is better if you don't. which I strongly recommend to ignore! I do not like at all some well-known "operating system" of a well-known company, but just ignoring it is a nice method to commit social suicide among computer users. *) > Actually, I'm going to take this a bit further (I don't think Java has this, > but why not): > > Let T be any object type and In be some interfaces. > > The following variable declarations could all be legal: > > T > ^T > ^I1 > ^I1 T > ^I1 I2 > ^I1 I2 T > ... You mean: legal types for a variable? A list of types separated by spaces? > In general: P can be a variable of type pointer of (n interfaces I1 .. In and > optionally one object type T). > > Legal assignments to P are objects of any type that implements all I1 .. In > (and is T or a descandant of T, if T is given). > > The internal representation of P consists of the actual address of the object > and n addresses that point to the first method of each of the n interfaces > inside the VMT of the actual type of the object. > > I hope this was understadable so far -- if not, I can try to explain again. I am not sure that I have understood it. Further explanation cannot hurt. How would the virtual method calls PointerToInterface:= @MyObject; PointerToInterface^.MyMethod; and PointerToObject:= @MyObject; PointerToObject^.MyMethod; work with this representation? I am sceptical about this "multiple pointer" representation because there are *many* places in the GPC front-end relying on the fact that all pointers have the same format. I don't even know all of them. > > That's the problem why I initially asked about MI. > > The problem would not be any easier with MI. > [Proof: You showed above that interfaces are just a special case of MI. ;-] I meant: It is easier with interfaces than with MI because they are just a special case. > > Does anybody know how C++ solves that problem? Or Java? Or Delphi? > > No, but from Delphi's interface IDs I gather it uses something like the > second way. (And since it runs under Windoze, efficiency doesn't matter, > anyway... ;-) One day, I will compile some Delphi stuff and look at the generated code in order to figure this out. (But I wouldn't mind if somebody were faster than I and would tell me the result ... ;-) > > But this is quite an interesting problem - not a technical one, how to > > implement this-or-that without interfering with that-or-this syntax from > > another dialect. Here we have a problem where it is not even clear that > > a fast (i.e. O(1)) solution exists. :-(-: > > There is a O(1) solution -- the first one! Now we have two of them: The solution with offsets stored in the object is O(1) as well. (-: Implement both? ;-) > It increases the memory needed for (pointer-to-)interface type variables/ > parameters, but this might just be the prize we have to pay. It's O(1) in > size and speed, and it takes more space than now only when one actually uses > interfaces. Doesn't seem too bad to me! What I am really afraid of is how much of GPC would break when we change the size of some pointers ... :-/ > So with the first solution, AFAICS, the ObjIDs for interfaces are not needed > (in contrary to what I said above) -- they can be accepted in Delphi > compatibility mode, but I see no need for them... Agreed. (With both solutions discussed above.) > > > If you used the address everywhere you use the ID now, you would know, > > > wouldn't you? > > > > > > [...] > > > > > > Yes, but what do you need to do with IDs? > > > > The unique ID can be stored in a stream; the address cannot. > > A valid point! But I think the IDs should be generated within the storing > routines, and resolved (to pointers) within the loading routines. This can > be done quite efficiently, O(n log n), perhaps O(n^2) worst case. No need > to keep the IDs during the (regular) operation, wasting memory and time. > > There may be some types that need a persistent ID (i.e. one that cannot > simply regenerated with each storing, for whatever reason), but then again, > ID should be a field of these special types only. I have *lots* of such types, but I agree that only those should have that ID. There's no need to equip *all* objects with an ID. > > Use: Think of a tree of objects holding numerical data. A method of > > an object somewhere in that tree wants to calculate something. For this > > purpose it needs some data stored elsewhere in the tree. Then the > > unique ID can be used to locate that other data object. > > For this purpose, I'd use a pointer to thar other object. The whole purpose of the ID is to *get* that pointer. > When storing the whole thing to a stream, the pointers can be converted to > (numerical) IDs that are unique to this data structure in this stream at this > time. While loading the stream, the IDs can be converted back to pointers. > (This takes some programming effort, but it's a one-time job! I think I could > program these conversions if necessary.) My problem is that I need a numerical value from some object somewhere in the application where I don't even know whether it already exists. Having IDs, I can do a search for the other object. If it exists, I get a pointer to it; otherwise I get `Nil' and can do some action to make the other object appear ... All this is done in a generalized `HandleEvent' method which will be in my `BaseObj'. Methods don't use up memory per instance, only per VMT which can be neglected, so this does not harm performance. > > > Where do you get the SelfIDs from? Perhaps a list of IDs stored in a parent > > > object? You could put the addresses there instead, couldn't you? > > > > The IDs must be arranged in a way that you can read off them what kind of > > object we have. > > ??? Now I think you lost me! > > I assume, by "kind of object" you mean its type, right? Yes. > But the type information is already there (through the VMT link), isn't it? > Any procedure can check the VMT link (together with the "IS" operator) to > examine the type of any object it has a pointer to -- and usually, type > destinctions should not be made be the caller at all, but by the called > object (through virtual methods). This example is one method how to implement the `is' operator. Another one - which seems the most practical for me and will probably be the way to go - is to store inheritance information in each VMT. > > And calls to `Foo' in instances of `MyObj' would yield a run-time error? > > No -- there can't be any instances of MyObj, the compiler should check this. > That's the main goal of the whole thing: to make these checks at > compile-time, not at run-time. This is how Delphi behaves? > 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. Hmm ... I essentially re-worte Turbo Vision to run in graphics mode, while introducing many extensions. (* I am calling the result "BO4" - Benutzeroberflaeche, 4. Versuch (German) which means user interface, 4. try. *) I paid 600DM (~$400) to get the source because I couldn't stand to derive a new class from just *everything*, re-implementing the same extensions in each new class everywhere which would have been placed most naturally in `tView'. (* Some weeks later, Borland reduced the price of the source to 50DM. *): > [IDs ...] > > > > And what kind of things would you do with an unique integer ID? > > > > Inter-process communication and message passing for one. > > No problem with pointers! (Assuming the objects reside in some kind of shared > memory, but otherwise an integer ID would be quite useless as well.) I think the point is to get the address of an object you are not even sure that it already is in memory. All this can be done with a common *method* of all objects (which doesn't waste space, see above). A unique ID in each object can be useful in the implementation of that method, but it does waste space, so I would vote against having it in the "mother of all objects". But since we won't restrict GPC to have exactly one class library, that's a matter of taste, IMHO. (Just my 2Pf.) > [... snip ...] > If things are done as I suggested, you could do things like: > > type t=object > const c:integer=2; {stored in VMT of x} > var cv:integer=3; {class variable; stored in VMT of x; syntax???} > v:integer; {stored in data area of o} > end; > > var o:t; > ... > o.v:=o.cv+o.v; > ... This syntax seems reasonable for me. However: Other suggestions? > > [...] > > One of the things I hate about some frameworks that will remain > > nameless is the multitude of ancestors. It makes it really tedious > > when you are trying to find out what is really going on in an object > > (sometimes having to plough through myriads of objects in myriads > > of units). Sometimes inheritance can be taken too far. > > You seem to be doing the other extreme. The former might be tedious and > confusing to use, especially at first sight, and it requires good > documentation, but the latter can lead to real problems if code from > different sources doesn't fit together. I agree that some way "in between" is the way to go. However, there are many points in Borland's object hierarchies which seem to me as if they were designed with the goal to avoid the exchange of source code. Not considering myself as a "free software extremist" I state that you can forget about many "hooks" in an object hierarchy (e.g. in Turbo Vision which I know best) if you are not worrying about someone else reading your source code (which is still the best documentation you can have for any library anyway). (After having studied TV's source code extensively I understand why Borland first didn't want everybody to read it ... ;-) Phew! That was a long e-mail ... Later, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, 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: [q] Pointer to function ?
by Peter Gerwinski 02 Jun '97

02 Jun '97

According to Patricio Domingues: > > I'm trying to use signals with GPC 2.0 under Linux (binary release...). > > But I have problems in assigning a function address to a pointer. > > [...] This is a known bug in GPC 2.0. Please upgrade to gpc-970510 (alpha version), available at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/. (The next - beta - version is in preparation. Please be patient ... some days ...) Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, 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: Portability questions (Arrays)
by Peter Gerwinski 02 Jun '97

02 Jun '97

According to Frank Heckenbach: > > The latter doesn't fit into the procedure above, but if "inc(p)" works, fine! It might be necessary at the moment to `inc ( p, SizeOf ( p^ ) )'. If so, it's a bug which I should fix. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, 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

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 June 1997