- Gpc - gnu.de

Re: OOP
by Frank Heckenbach 08 Jun '97

08 Jun '97

Peter Gerwinski wrote: > > BTW: Do TV programs actually rely on the zeroing out, or is this just a > > paranoia initialization? > > They do. Bad style! Well, at least then there should be a BIG warning in the BPCompat objects.pas not to use the library with long strings or other schemata or any initalized fields... > > [String constants as Object IDs ...] > > > > I don't think so. If Delphi does it in a bad way, we don't have to duplicate > > that. But it would be good if a Delphi user could actually check what Delphi > > does. > > I don't think it's so bad: Strings are more flexible than Integers. I really > like to index a `RessourceFile' (in TV) with Strings ... As Pierre said: string comparison are less efficient than integer compares, and generally I think *internal* things (i.e. things that must only be read by computers, not by humans) should use integers rather than strings when there's no real need for strings. Resource files, AFAIK, are binary files, anyway, so what good would it be to have some strings scattered in them? A different thing would be textual "resource" files (e.g. like Windoze .ini files): for such things it can be useful to have a string ID (class name), with the compiler switch we discussed, *additionally*, but I think the primary ID should be an integer. (BTW: It might seem that string IDs are "more unique" than integer IDs, but I think the opposite is the case: many programmers will write some "TEdit" class (or "TWindow", "TString", ...), but with integer IDs there are no problems if they choose a unique programmer ID first.) BTW: The compiler switch for the string class names could perhaps be saved if the VMTs are generated in the main program (we discussed this for other reasons, anyway). Then, the compiler could know if any part of the program referred to a string ID (this information would have to be stored in the .gpi file for units and modules), so the compiler could decide by itself whether or not to include the string ID. The same, of course, is true for the integer ID, so any program will contain just those ID(s) that it uses. So both IDs could coexist peacefully... :-) Syntax proposal: Object(...)[StringID,NumID] Either or both IDs can be omitted. NumID defaults to 0, StringID to the class name (identifier). Accessible (readable) through fields ("object constants") called "ClassName" and "ClassID". > > If the "other program" is part of the standard library, it would be ok (just > > adapting our library to accept integers). Otherwise perhaps declare a > > function to convert a numeric ID to a string. This function would have to be > > inserted into the Delphi source then, but with a dummy function declared in > > Delphi, the code could still be used in Delphi. > > Anyway, I have more and more the impression that "Delphi compatibility" > users desire does not mean that the GNU Pascal compiler must be able to > compile Delphi's VCL, but that GNU Pascal has its own "VCL" with a 100% > compatible API. That's what I meant: if the format of the ID (string or integer) is only relied upon by the library, we could do it differently in gpc. But I'm not really convinced that Delphi handles these IDs as strings, could someone please check it out? > > BTW: What about the QueryInterface things? They might make "100% source > > compatibility" with Delphi impossible, anyway, as soon as interfaces are > > used. > > ??? Sorry, I don't understand. I don't either... ;-) I mean, I don't really understand what QueryInterface does, or how it's used, but AFAI understood it, it's needed to access interfaces. If that's right, interface acces in Delphi and gpc might be so different that programs that use interfaces simply can't compile with Delphi and gpc at the same time (without some {$IFDEF}s, of course). Any Delphi users to explain this or show some code that uses interfaces? > > I think I've found a third way, one that doesn't influence the pointer format > > and doesn't blow up the objects. It does, however, waste some space in the > > VMTs. I'm sending it to you by private mail (mainly because it's easier for > > me to describe it in German) -- sorry to other readers of the list who are > > interested in this discussion, but we'll post the results back to the list > > -- whatever it will be finally... > > One pre-result: I like that third method, but it causes some techical > problems as well. This task *is* a nontrivial one! Next pre-result: We're getting on! I think we can use this way... :-) > > But how many fields and which type??? I don't think that's a good idea. > > One additional field of type "pointer to base object" will allow to > store as much additional information as desired with the object. In which class, and pointer to which class? Sure, a pointer to TObject could do anything, but would require type casts (which I consider bad style), or absolute declarations (even worse). > Some additional Boolean fields, stored in a packed array, cannot hurt. > > See `tree.*' in the GCC source code for an example of what I mean with > "extensibility". The "tree nodes" used in the GCC and GPC front-end are > in fact Objects (written in C, not in C++!), and they contain such > extension fields at some central nodes in the object tree. Sorry, I don't really feel like wading through 100kB of C code now, but I guess they put in the "unused" fields because they're emulating objects -- for lack of an inheritance mechanism that allows to add fields when they're really needed. So I don't see how this would apply to gpc OOP. > > Actually, this is quite a general principle to get something like "separate > > inheritance" (of different parts of an object), by splitting up the object > > into several part-objects. There is an overhead (one additional pointer and > > its dereferencing), OTOH one can often eliminate case discriminations by > > clever use of virtual methods in the new part-objects. > > :-) Just what I proposed above: One additional pointer. > It seems that we in fact agree, but we chose different words for it. Not completely: my suggestion is to introduce pointers to appropriate types, e.g. pointers to some kind of video objects from all classes that access video. The (abstract) video class would provide the services required by those classes. That's a bit more specific than just a general purpose pointer. Another thing (not belonging to the topics above, but I didn't want to start a new mail): I think it could be useful to let the "IS" operator do an implicit type cast, so e.g. the following would compile: type a=object end; b=object(a) c:integer end; var d:^a; begin if d^ is b then writeln(d^.c) end. So when an "if" condition contains just one "is"-comparison (no other conditions with "and" or "or"), the object should be type cast to the actual type for the scope of the "then" statement. (Of course, this could be generalized to more compilcated conditions, but I think this simple case would suffice for most purposes.) I don't know how difficult this is to implement, but it would be a nice feature. E.g., in a program I have some situations like: if CurrentEditor^ is TTextEditor then TTextEditor(CurrentEditor^).TextSearch(...) I think this type cast should be superfluous (from a "high level" point of view). (Of course, the "is" currently is a "TypeOf" comparison.) -- 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

Exit extension.
by Bernhard Tschirren 08 Jun '97

08 Jun '97

I have always missed (in BP) an extension to Exit in the form of Exit(RetValue), just like C's return. Its not important, but its something that I have always wanted :-) ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: GPM???
by Bernhard Tschirren 08 Jun '97

08 Jun '97

>If it looks weird for you, never mind, it does so for me as well. You don't >need to worry about all this unless you want to change from UCSD-style Units >to EP-style Modules. ;-) It sure does look a little wierd (from a BP standpoint). But I suppose standards are there to make life more complicating :-) >From another email: > Maybe we can savely drop the `.gpm' file for Units. The only thing I am > worrying about is whether it will still be possible then to use Modules and > Units in the same project. But I will check ... Most (normal?!?) people would only use one type of unit in their projects anyway. I agree with Frank Heckenbach, I also don't like to have many files around. Cheers ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Procedural types
by Bernhard Tschirren 08 Jun '97

08 Jun '97

Here I am again! :-) I have yet another slight problem... The GPC procedural types do not allow VAR parameters! I looked through all the documentation but couldn't find any way of doing it - other than using pointers. Im sure a feature like this was not overlooked! :-) ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Enumerated types
by Bernhard Tschirren 08 Jun '97

08 Jun '97

Is it possible to specify the value of an enumerated type? I was trying to port a C header file which did something like this: typedef enum hello_everybody { hello_error = -1, hello_first = 0, hello_second, hello_third ... Can this be done with GPC? Thanks ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: License question...
by Peter Gerwinski 06 Jun '97

06 Jun '97

According to Orlando Llanes: > > Thanks for the help with the port statements! I figure that $define'ing > them will save time because of no stack operations (right? :}). Right. (Except the `volatile' problem Juki pointed out, GPC should do all this automatically with `-O3', but until that day, you can work around using the (*$define foo(bar) ... *) kludge.) > 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. This does not conflict with the license at all. Myself am planning to make a living with programs I will write with GNU Pascal. (At the moment, I still write most of them with Borland Pascal, but I already sold one written with GPC ... :) > I will be writing my own Game Libraries, and am willing to make them free > under GNU to develop commercially or for education. Be welcome to do that! :) I suggest to put it under the LGPL, not the ordinary GPL, because then it's easier to use it with programs you don't want to release the source. * It is NOT required that you publish the source of your programs when using an LGPLed library; when using a GPLed library, this IS required unless stated otherwise explicitly in its license. * When using an LGPLed library, you must ensure that the client can modify (e.g. upgrade) the library, and your program will work with the new version. The easiest way to achieve this is to link it dynamically. * When using a GPLed library, you still have the possibility to write a free (GPLed) program which cooperates with your own program. Then you can sell both. (It's OKAY to charge a fee - as much as you wish and your clients are willing to pay - for the free program, but the clients must be allowed to redistribute the free program.) (While I was first shocked by the thought that I would have to release the source of some of my programs, I meanwhile think that the idea is not that bad: It makes it easier to fix bugs when the client has the source!) > 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? The definitions of "commercial" and "free" software don't exclude each other. You are welcome to distribute free software, e.g. GNU Pascal itself, for a fee. There are companies like Cygnus Solutions making a living this way. For details about "selling free software", see http://www.gnu.ai.mit.edu/philosophy/selling.html mirrored in Germany as http://agnes.dida.physik.uni-essen.de/~gnu/philosophy/selling.html but - once again - it is NO PROBLEM to use GNU Pascal for writing non-free software. I only recommend to read the licenses of all libraries you are using carefully - including the GNU Pascal run-time library. (... which you should do anyway, regardless which compiler and libraries you are going to use.) 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: Machine Code...
by Peter Gerwinski 06 Jun '97

06 Jun '97

Juki wrote: > PredatorZeta wrote: > > Warning: return value of function not assigned > > Right, gpc does not handle this properly. [...] Now it does. :-) > > =8-||||| AAAAAAAARRRRGGGHHH!!!8-)) Whatta the lines 7 and 8 do?????? > > NOTHING!!! > > [...] > > I think this is because the return value of the function > is declared volatile to prevent optimization screwing > it up. I remember having problems with this, so please don't > remove the volatile stuff until the real problem is tracked. > [...] I'll see what I can do against that ... 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: OOP
by Peter Gerwinski 06 Jun '97

06 Jun '97

According to Frank Heckenbach: > > > At least a `BPcompat Objects' Unit *must* have this FillChar. :-| > > Hmmm... there could be problems if an object in a ported BP program has a > string field (at least until short strings are implemented and "string[]" > automatically generates short strings). I hope that I will be able to implement them not too far in the future. > BTW: Do TV programs actually rely on the zeroing out, or is this just a > paranoia initialization? They do. > [...] Since gpc > favours speed instead of size, I think it's good to do the initialization > outside. Agreed. > But then the question is whether to initialize the VMT before the call. > With the method below, it's simple: initialize it if (and only if) it > hasn't been initialized before. Exactly. This implies that pre-initialization is necessary. > I think this is a good idea. Perhaps also resetting the VMT after a > destructor call (which is superfluous in a Dispose statement, of course). Yes. > [String constants as Object IDs ...] > > I don't think so. If Delphi does it in a bad way, we don't have to duplicate > that. But it would be good if a Delphi user could actually check what Delphi > does. I don't think it's so bad: Strings are more flexible than Integers. I really like to index a `RessourceFile' (in TV) with Strings ... > If the "other prorgam" is part of the standard library, it would be ok (just > adapting our library to accept integers). Otherwise perhaps declare a > function to convert a numeric ID to a string. This function would have to be > inserted into the Delphi source then, but with a dummy function declared in > Delphi, the code could still be used in Delphi. Anyway, I have more and more the impression that "Delphi compatibility" users desire does not mean that the GNU Pascal compiler must be able to compile Delphi's VCL, but that GNU Pascal has its own "VCL" with a 100% compatible API. > BTW: What about the QueryInterface things? They might make "100% source > compatibility" with Delphi impossible, anyway, as soon as interfaces are > used. ??? Sorry, I don't understand. > Doesn't the same apply to your method? You pointers are non-standard, too. > E.g., when you want to convert them to an untyped pointer, you have to > subtract the offset from them. Yes. :-( A lot of work, which invites for many hard-to-decect errors. > I think I've found a third way, one that doesn't influence the pointer format > and doesn't blow up the objects. It does, however, waste some space in the > VMTs. I'm sending it to you by private mail (mainly because it's easier for > me to describe it in German) -- sorry to other readers of the list who are > interested in this discussion, but we'll post the results back to the list > -- whatever it will be finally... One pre-result: I like that third method, but it causes some techical problems as well. This task *is* a nontrivial one! > AFAIS, this is the "aliasing bug" and can be solved with pointer-pointers. > (See my reply to the chief, later.) Where would that pointer-pointer reside, and who would initialize it? When the object shows up, it must ensure that some other objects which might not yet be in memory will be able to find the pointer to it, so they can set up their pointer-pointers. This task works without IDs if (and only if?) both objects are loaded at the same time. > No, you don't disagree! :-) I said "if this doesn't work well..." -- > obviously it did after your changes! :-) It did, and it still does. :) However, BO4 is still 16-bit technology, supports every graphics card from CGA, Hercules, etc. to VGA (and even the EGC card, which I saw only at two places ...), assumes DOS 2.11 and at least one floopy disk drive (hard disk recommended, but not required), etc. It's time for something more powerful and not restricted by Borland's copyright! > But how many fields and which type??? I don't think that's a good idea. One additional field of type "pointer to base object" will allow to store as much additional information as desired with the object. Some additional Boolean fields, stored in a packed array, cannot hurt. See `tree.*' in the GCC source code for an example of what I mean with "extensibility". The "tree nodes" used in the GCC and GPC front-end are in fact Objects (written in C, not in C++!), and they contain such extension fields at some central nodes in the object tree. > Actually, this is quite a general principle to get something like "separate > inheritance" (of different parts of an object), by splitting up the object > into several part-objects. There is an overhead (one additional pointer and > its dereferencing), OTOH one can often eliminate case discriminations by > clever use of virtual methods in the new part-objects. :-) Just what I proposed above: One additional pointer. It seems that we in fact agree, but we chose different words for it. Greetings, Peter

1 0

Re: OOP
by The African Chief 06 Jun '97

06 Jun '97

On Thu, 29 May 1997 15:59:51 -0400 (EDT) Pierre Phaneuf <pp(a)dilu.ml.org> wrote: [...] >> Yes, that is correct. The handle is not not necessary in TObject - but >> I still feel that it does no harm to have it there. > >What if it did? How can it? >What if I use a windowing system that has long integers for window handles? 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. 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). >You have a field there that's basically of *no use*. Ok. >> >The instance pointer is an unique ID, why have another redundant one? >> >> Yes, the instance pointer is a unique ID. But this assumes that you >> know the instance pointer. This will be the case in most situations, >> but it won't always be the case. And, like I said in another post, there >> are things that you can do with integers that you cannot do with >> pointers. > >I don't know. Why would you know more the integer ID than the instance >pointer? 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 ); If Assigned ( p ) then begin If p^.Name = 'CHIEFDIALOG' then { blah blah } else If p^.Name = 'CHIEFCONTROL' then {blah blah} else {blah blah}; end; end; > And what kind of things would you do with an unique integer ID? Inter-process communication and message passing for one. Saving and storing things for another - the objects themselves, the state of the desktop, the whole environment in which the program is running, etc. 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

3 3

Re: OOP
by Frank Heckenbach 05 Jun '97

05 Jun '97

Peter Gerwinski wrote: > > > 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). The danger is with (possibly unknown) descendants that declare such types. > At least a `BPcompat Objects' Unit *must* have this FillChar. :-| Hmmm... there could be problems if an object in a ported BP program has a string field (at least until short strings are implemented and "string[]" automatically generates short strings). BTW: Do TV programs actually rely on the zeroing out, or is this just a paranoia initialization? > It's done like this at the moment, but BP does it in another way. > As long as I don't know why (i.e. I suspect some disadvantages of the > method used currently which didn't show up yet), I am very careful about > fixing it. BP must do it within the constructor, because it allocates the memory within the constructor (in a "New(p,Init)" construct). This reduces the question to: why do they allocate the memory within the constructor? I suppose they do it in order to use a common "Constructor support routine" (in objh.asm) -- some kind of size optimization at the expense of speed. They do that in other places, too, most prominently the range and stack checks (which are explicit procedure calls that save a few bytes but cause a big slowdown). Since gpc favours speed instead of size, I think it's good to do the initialization outside. > > But there is another problem, namely to decide whether to call the > > constructor virtually (i.e. looking up its address via the VMT) or > > "statically". > > What's the problem? It's just calling another virtual method. Right. I had forgotten how gpc calls constructors. But then the question is whether to initialize the VMT before the call. With the method below, it's simple: initialize it if (and only if) it hasn't been initialized before. What must be prevented is that in the following code, the "Load" call would "initialize" p's VMT link to that of TObject (assuming Load is a virtual constructor): p:PObject ... Getmem(p,...); AssignType(p^,Typeof(TFooObject)); p^.Load(Stream); > It is possible: I would have to pre-initialize (set the VMT to zero) > each object variable when created: global variables at startup time, local > variables when the procedure is entered, dynamical variables when `new'ed > (without constructor call which would make the pre-initialization > superfluous). I think this is a good idea. Perhaps also resetting the VMT after a destructor call (which is superfluous in a Dispose statement, of course). > > I could perhaps help with designing the structures and algorithms (see > > below ;-), if desired, > > but probably not with hacking the compiler... > > Why not? GPC doesn't bite! (-; If it does, this is a bug which must be > reported! :-) Perhaps gcc, that gpc is written in, bites... > (* There is only one problem with hacking GPC: It's addictive ... :*) Yes, that's the main problem since my Recursive Time-Doubler has broken. ;-) > > > const > > > SIID_IActiveScriptSiteWindow = '{D10F6761-83E9-11cf-8F20-00805F2CD064}'; > > I cannot believe that. Why should they enter it as a String constant, then? Perhaps to make it more "readable" with the separating hyphens??? > And there are braces, etc. No, I believe that this is indeed a string to be > interpreted by some program lying around somewhere ... so we should provide a > string, too. :-| I don't think so. If Delphi does it in a bad way, we don't have to duplicate that. But it would be good if a Delphi user could actually check what Delphi does. > > Anyway, I think at least in gpc the internal representation should be an > > integer, not a string. > > Since that other program obviously wants the number as a string surrounded by > braces, this would be no good idea with respect to compatibility. If the "other prorgam" is part of the standard library, it would be ok (just adapting our library to accept integers). Otherwise perhaps declare a function to convert a numeric ID to a string. This function would have to be inserted into the Delphi source then, but with a dummy function declared in Delphi, the code could still be used in Delphi. BTW: What about the QueryInterface things? They might make "100% source compatibility" with Delphi impossible, anyway, as soon as interfaces are used. > I understand that this will work, but I fear the many special cases it would > cause to implement a non-standard-format pointer: They would be allowed in > all contexts where "ordinary" pointers are allowed, so all internal GPC > routines handling pointers would have to be modified. :-( Doesn't the same apply to your method? You pointers are non-standard, too. E.g., when you want to convert them to an untyped pointer, you have to subtract the offset from them. > BTW, using this method, we could also implement pointers to "ordinary" objects > thus saving the VMT field in each instance. It's kind of an "external field" > for each object instance ... Right, though I doubt one would usually save memory this way, because "most" (I guess) objects have a pointer pointing to them, many objects have even more than one pointer. And it would complicate (to the compiler) accessing VMT fields (ObjID, object constants, class variables). > Facing the enormous technical problems with your method I am preparing to > implement mine. :(Yours is nice too - sorry - and very innovative. Perhaps > you want to try yourself on it?:) I think I've found a third way, one that doesn't influence the pointer format and doesn't blow up the objects. It does, however, waste some space in the VMTs. I'm sending it to you by private mail (mainly because it's easier for me to describe it in German) -- sorry to other readers of the list who are interested in this discussion, but we'll post the results back to the list -- whatever it will be finally... > > But I still can't understand why you can't simply use the pointer from the > > beginning, i.e. when you assign IDs (like "Factor1ID := Factor1^.ID"), you > > just do "Factor1ID := @Factor1". Then you have the pointer when you need it. > > Is it that the whole object "Factor1" can change (be reallocated), not only > > its contents change -- the "aliasing bug"? [...] > > Here is an example from praxis. > [skipped desription] AFAIS, this is the "aliasing bug" and can be solved with pointer-pointers. (See my reply to the chief, later.) > I agree this is a design fault in TV, but I doubt that it's is possible to > design a class library which will never need changes in the innermost part ... No, not never. But I was objecting to the idea that everyone does their own changes in such a library just when they need them at the moment. > > If this doesn't work well (i.e. if many diffs between text and graphics > > version remain), this might be an indication that TV and TV/graphics are > > simply different enough to not share the same classes. (And actually, one > > would hardly ever use objects of both packages in the same program.) So they > > could be simply two packages with "similar" source then... > > Here I disagree. I have written some programs which can run, on demand, in > text mode as well as in graphics mode, and *all* objects are shared between > "both packages" (which are in fact one). No, you don't disagree! :-) I said "if this doesn't work well..." -- obviously it did after your changes! :-) > 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.) But how many fields and which type??? I don't think that's a good idea. Since I don't know what kind of field these are, I'm not sure if the following applies to the situation: Put the mode-dependent fields (those that change in all the view objects between text and graphic mode) into a separate object. There could be an (abstract) superclass, and special subclasses for text resp. graphics mode. The actual objects would contain a pointer of the abstract spureclass type, and the constructors would create text or graphics mode objects as desired. Of course, this does involve changes to TV, but such changes that "improve" its design (here: make it more flexible), not putting things in it that don't belong there. Actually, this is quite a general principle to get something like "separate inheritance" (of different parts of an object), by splitting up the object into several part-objects. There is an overhead (one additional pointer and its dereferencing), OTOH one can often eliminate case discriminations by clever use of virtual methods in the new part-objects. -- 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

2 1

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

Re: OOP
by Peter Gerwinski 03 Jun '97

03 Jun '97

According to Frank Heckenbach: > > According to myself (Peter Gerwinski): > > > 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. > > I don't think it's a problem, because if a constructor is called virtually, > the object must have been initialized before (otherwise the constructor's > address couldn't be found). It's done like this at the moment, but BP does it in another way. As long as I don't know why (i.e. I suspect some disadvantages of the method used currently which didn't show up yet), I am very careful about fixing it. > (I'm assuming, "initializing" means only setting > the VMT link, or does it do anything more?) Yes. (Read: The `or' condition holds; one of both is `true'. (The first.;)) > But there is another problem, namely to decide whether to call the > constructor virtually (i.e. looking up its address via the VMT) or > "statically". What's the problem? It's just calling another virtual method. > If there's a reliable way to detect if an object has been > initialized (like we discussed earlier), this would be easy (virtually if > initialized, statically otherwise). It is possible: I would have to pre-initialize (set the VMT to zero) each object variable when created: global variables at startup time, local variables when the procedure is entered, dynamical variables when `new'ed (without constructor call which would make the pre-initialization superfluous). > This means that Fillchar'ing an object with 0 is a bad idea (even if you > exclude the VMT link)! > So, Pierre, it seems like you'll have to renounce this feature from TV. As I wrote in my other mail, it must be present in BPcompat's "Objects" Unit for compatbilitie's sake. > > [`Interface' keyword ...] > > As a scientific model, it seems good (unifying as much as possible), but > I think in actual programs, it's easier to distinguish by using different > keywords. Perhaps the rules are also more comprehensible this way, and > programmers familiar with Delphi or Java will recognize what they know. Agreed. > I could perhaps help with designing the structures and algorithms (see > below ;-), if desired, Yes, please! > but probably not with hacking the compiler... Why not? GPC doesn't bite! (-; If it does, this is a bug which must be reported! :-) (* There is only one problem with hacking GPC: It's addictive ... :*) > > > - 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}'; > > Yes, I saw this too, but didn't spend much thought about it. > This string constant looks suspiciously like a 32-digit hex number, i.e. a > 128 bit integer. Does Delphi convert this to an integer internally (Delphi > users, please!)? I cannot believe that. Why should they enter it as a String constant, then? And there are braces, etc. No, I believe that this is indeed a string to be interpreted by some program lying around somewhere ... so we should provide a string, too. :-| > Anyway, I think at least in gpc the internal representation should be an > integer, not a string. Since that other program obviously wants the number as a string surrounded by braces, this would be no good idea with respect to compatibility. > [Representing pointers to interfaces as multiple pointers ...] I understand that this will work, but I fear the many special cases it would cause to implement a non-standard-format pointer: They would be allowed in all contexts where "ordinary" pointers are allowed, so all internal GPC routines handling pointers would have to be modified. :-( BTW, using this method, we could also implement pointers to "ordinary" objects thus saving the VMT field in each instance. It's kind of an "external field" for each object instance ... > You mean something like the following? > > VMT of T: > Offset Field > 0 Size > 4 NegSize > 8 [... perhaps ObjID and such] > 20 Offset of I, i.e. Pointer to I1 in *this* VMT > 24 Offset of J, i.e. Pointer to I2 in *this* VMT > 28 M1 > 32 M2 > 36 I1 > 40 I2 > > V: > Offset Field > 0 Pointer to VMT of T > 4 4 (Interface offset I) > 8 8 (Interface offset J) > 12 F1 > 16 F2 Yes. > An interesting method, AFAICS it will work, too. > > The disadvantage is that instances and VMTs get bigger. In my method, > pointers to interfaces get bigger, so that's a tradeoff. > > I think, however, that pointers to interfaces are rarer (and mostly they > appear as parameters, i.e. only temporarily), so my method might be a bit > more economical with memory. I am not sure about that. Remember that most objects will contain pointers to interfaces if an interfaces is implemented at a relatively low place in the object hierarchy. Then they will be blown up - perhaps more than they would if getting one integer field for each inherited interface. Furthermore I think that pointers are often used in structures where the programmer wants to save space for some reason, while object instances are allocated on the heap and usually aren't expected to be "small". Facing the enormous technical problems with your method I am preparing to implement mine. :(Yours is nice too - sorry - and very innovative. Perhaps you want to try yourself on it?:) > [Lots of interesting technical details snipped ...] > > > 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, > > Really -- their IDs must be the very same in a different program run? > If so, why? I'm asking just out of curiosity. > > [...] > > But I still can't understand why you can't simply use the pointer from the > beginning, i.e. when you assign IDs (like "Factor1ID := Factor1^.ID"), you > just do "Factor1ID := @Factor1". Then you have the pointer when you need it. > Is it that the whole object "Factor1" can change (be reallocated), not only > its contents change -- the "aliasing bug"? [...] The object may be reallocated, but it also may vanish completely. Here is an example from praxis. We have a CAD program dealing with staircases. Suppose that the desktop currently contains one dialog holding numerical data about the staircase plus zero or more drawings of the staircase from different view points. Now the user changes one value in the dialog. We want all drawings to update immediately. Since it is not clear which drawings are currently on the desktop, the dialog does not have pointers to them. (More precisely: It has pointers but must ensure from time to time that they are still valid.) Instead, it sends a message to all windows and asks for drawings currently displaying "this" staircase. To specify the "this", the unique ID of the staircase object (as entered by the user) is used. The other direction is more interesting and makes more trouble at the moment *because* we use pointers instead of IDs. Each drawing has a pointer to the staircase it is displaying. (For obvious reasons, it is necessary for the drawing to know about the staircase.) Now the user may decide to close the staircase dialog and to continue his work only with the drawing(s). Then the pointer becomes invalid, and we must do some administrative work to set it to `Nil' at exactly the correct time. The ID of the staircase however would remain valid; a "search the staircase" function could return `Nil' now or even decide to reload the staircase from disk. (More about this on demand.;) > [`is' operator and abstract objects snipped] > This sounds like a bad design of TV (no surprise to me...). If designed well, > changes should only be necessary in relatively few places. I agree this is a design fault in TV, but I doubt that it's is possible to design a class library which will never need changes in the innermost part ... (That's what new, incompatible versions are for.) > Of course, if changes are made to "gpc's TV" to make it more easily adaptable > to graphics mode (or whatever), these changes could go into the main > distribution. The actual graphics mode changes (which should be rather few > then) should go into a separate package. > > If this doesn't work well (i.e. if many diffs between text and graphics > version remain), this might be an indication that TV and TV/graphics are > simply different enough to not share the same classes. (And actually, one > would hardly ever use objects of both packages in the same program.) So they > could be simply two packages with "similar" source then... Here I disagree. I have written some programs which can run, on demand, in text mode as well as in graphics mode, and *all* objects are shared between "both packages" (which are in fact one). > [Borland TV miseria ...] > > > And let us work on > > something which will make the world forget that TV did ever exist! :-) > > ...and Borland as well (if they behave like this) -- sad to say so... Sad, but I agree. I always hoped that they would be a "counterpart" of M$, but since they obviously don't intend to support anything non-M$, they seem more like "BG's dog" for me ... > > I have attempted to compile TVision with GPC, but it lacked to much object > > support. > > ...and x86 real mode assembler support, I suppose... ;-( What is missing in BP7 object support? I think we are not too far away from having a GPC which can compile (a patched version of) TV. Some assembler sections would have been re-written completely; some assumptions about internal representations would have changed (or - even better - wiped out), but in essential, GPC meanwhile supports most of BP7. Now it must become more stable ... 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: 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

Re: GPM???
by Peter Gerwinski 02 Jun '97

02 Jun '97

According to Frank Heckenbach: > > Just an idea (since I don't like to have too many files around): it might be > possible to have one file (with the unit name = file name) in the case of > units and two files (one with the module name (= file name?) and one with > the interface name) in the case of modules. Not urgent, of course... Maybe we can savely drop the `.gpm' file for Units. The only thing I am worrying about is whether it will still be possible then to use Modules and Units in the same project. But I will check ... 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

[q] Pointer to function ?
by Patricio Domingues 02 Jun '97

02 Jun '97

Hi, 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. I'm basing my signal routine in the 'Function pointers' example, described in the HTML documentation of GPC, but it doesn't seem to work. Here goes the example and the compilation error: &>----------------------------------------------------------------------------< program zap(output); type proc_ptr = ^ procedure (integer); var pvar : proc_ptr; procedure write_int(i: integer); begin writeln ('Integer: ',i:1); end; begin (* PVAR points to function WRITE_IT *) pvar := & write_int; (* Dereferencing a function pointer calls the function *) pvar^(12345); end. >----------------------------------------------------------------------------< And GPC output is: example.pas: In function `program_Zap': example.pas:16: too few arguments to function `Write_int' example.pas:16: invalid lvalue in unary `&' >----------------------------------------------------------------------------< It seems that GPC is not understanding that ' & Write_int' as it should. So , what am I doing wrong ? thanks for any help, Patricio.

1 0

Re: OOP
by Frank Heckenbach 02 Jun '97

02 Jun '97

Peter Gerwinski 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. Fine. :-) > 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. I don't think it's a problem, because if a constructor is called virtually, the object must have been initialized before (otherwise the constructor's address couldn't be found). (I'm assuming, "initializing" means only setting the VMT link, or does it do anything more?) But there is another problem, namely to decide whether to call the constructor virtually (i.e. looking up its address via the VMT) or "statically". If there's a reliable way to detect if an object has been initialized (like we discussed earlier), this would be easy (virtually if initialized, statically otherwise). Otherwise I guess, one needs more complicated rules, like: always statically when used with "New" or on variables of object types (in contrast to pointers). And virtually in the other cases? I'm not so sure -- so it would be better to have a reliable way to detect if an object has been initialized -- would be nice anyway. > 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.) This means that Fillchar'ing an object with 0 is a bad idea (even if you exclude the VMT link)! So, Pierre, it seems like you'll have to renounce this feature from TV. > > > `--store-object-names', and switched ON in Delphi compatibility mode. > > > > ... and OFF otherwise! > > Of course! That's what I meant. :-) I thought so -- just wanted to make really clear. > 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. But actually this is the essential purpose of typing at all... ;-) > 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. As a scientific model, it seems good (unifying as much as possible), but I think in actual programs, it's easier to distinguish by using different keywords. Perhaps the rules are also more comprehensible this way, and programmers familiar with Delphi or Java will recognize what they know. > (-: Great! It seems that I have got it! This increases the chance that > I will be able to implement all this into GPC. :-) I could perhaps help with designing the structures and algorithms (see below ;-), if desired, but probably not with hacking the compiler... > > - 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}'; Yes, I saw this too, but didn't spend much thought about it. This string constant looks suspiciously like a 32-digit hex number, i.e. a 128 bit integer. Does Delphi convert this to an integer internally (Delphi users, please!)? And what are the (usual) meanings of the different "parts" of this string? Anyway, I think at least in gpc the internal representation should be an integer, not a string. If necessary for compatibility, it might be a good feature to convert such strings to numbers automatically -- though in native gpc code one would rather write it as "$D10F676183E911cf8F2000805F2CD064" -- do/will such big numbers work? (Of course, one would not actually write such numbers every time, but use some constants and add "small numbers" to them.) > I agree, *and* having that we could claim more compatibility to Delphi thus > making GPC more attractive for a lot of possible users. *If* that's really Delphi-compatible! Things like this "QueryInterface" make me think things are more compilcated in Delphi. > > 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. There's a very simple reason: because they have abstract methods! (Unless empty interfaces, of course, but I doubt someone would want to instantiate an empty interface...) > > 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. To illustrate what I mean, let's say interface I declares methods I1 and I2. Type T has fields F1, F2, declares methods M1, M2 and implements I (and I's methods, of course). Variable V of type T. This would look like (assuming everything is 4 bytes, just for simplicity): V: Offset Field 0 Pointer to VMT of T 4 F1 8 F2 VMT of T: Offset Field 0 Size 4 NegSize 8 [... perhaps ObjID and such] 20* M1 24 M2 28 I1 32 I2 * arbitrarily chosen So the methods of I start at offset 28 in the VMT of type T -- and in the VMT of all descendants of T (!), and the compiler knows that. Let P be of type ^I, and let's assign "P:=@V". Then the internal representation of P would look like Offset Field 0 Pointer to the fields of V, i.e. "@V" in the conventional sense 4 (Pointer to VMT of T) + 28 ("VMT link to I within T") If we go further and assume that J is a sub-interface of I that has just I2, then J's methods start 32 in T, and generally they start at n+4 in the VMT of a type that implements I with I's methods starting at n. So if Q is of type ^J, it's legal to assign "Q:=P". Internally, it would just copy the first "field" of P (the actual pointer) to Q, and add 4 to the second one in Q. > 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. > > [...] > > This implies: > > - Each instance of each object gets one additional integer field for each > interface the object inherits from. Including each interface those interfaces inherit from -- which *might* be quite a few... > - Each VMT gets additional pointer fields pointing to the VMTs of the > interfaces the object inherits from. You mean something like the following? VMT of T: Offset Field 0 Size 4 NegSize 8 [... perhaps ObjID and such] 20 Offset of I, i.e. Pointer to I1 in *this* VMT 24 Offset of J, i.e. Pointer to I2 in *this* VMT 28 M1 32 M2 36 I1 40 I2 V: Offset Field 0 Pointer to VMT of T 4 4 (Interface offset I) 8 8 (Interface offset J) 12 F1 16 F2 > - 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. Also from "pointer to interface" to "pointer of sub-interrface". For sub-interfaces (AFAICS), their offsets must be stored at a fixed position after (or before) the main interface's offset -- in my example above, J's offset must immediately follow I's, so any ^I can be assigned to a ^J by adding 4. However, this seems possible to guarantee. An interesting method, AFAICS it will work, too. The disadvantage is that instances and VMTs get bigger. In my method, pointers to interfaces get bigger, so that's a tradeoff. I think, however, that pointers to interfaces are rarer (and mostly they appear as parameters, i.e. only temporarily), so my method might be a bit more economical with memory. > 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; I think I heard about such a "weird machine" recently... ;-) > This means that we mustn't introduce another format for pointers I didn't find that node in my info file, but well... What kind of pointers are they talking about? Pointers in C, I assume. What effect has this on what we call a pointer in Pascal? AFAICS, it's just a matter of definition. So let's call it an "i-pointer" (pointer to an interface) or whatever, consisting of a (conventional) pointer and a VMT pointer. What should prevent us from creating such a data structure as an i-pointer (a structure that can even be declared in plain Pascal as a record)? BTW: Don't they also (implicitly or expicitly) assume that a pointer contains the address of the first byte of the data it references, which is not the case for your way of interface pointers? So the same argument ("i-pointer") would apply to this kind of pointers, too, wouldn't it? > (* 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. *) DJGPP and EMX are not just plain DO$ -- especially concerning pointers, maybe they meant not supporting x86 real mode... > > 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? The syntax is another issue... - but considering that many interfaces (at least in the typical Java examples) have names ending in "-able", this could be a relatively "^readable understandable syntax". ;-) Of course, I don't think one would need such declarations often, but perhaps sometimes... -- especially the relatively simple form "^I1 T", as in "^streamable TObject" could be of some practical use. In your model, this is possible, too, but it complicates calling methods of T and accessing fields of T a little. If someone has better suggestions for the syntax (for this and the other stuff), please! (* BTW: Theoretically, this is quite interesting: if one consideres (mathematically) types as sets (of all possible instances of the type and -- in the case of object types -- all possible derived types), the typing mechanisms correspond to some set operations (subrange: subset; record/array: set product; variant record: union; "set of": power set; derived object type: subset). The one above would be the intersection, which is not present up to now (because there isn't much there that could be intersected nontrivially without MI/interfaces). *) > > 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 > [see below] > work with this representation? > > PointerToInterface:= @MyObject; - Use "@MyObject" as the first "field" of "PointerToInterface" - For each interface that "PointerToInterface" points to: - Get the VMT link of MyObject - Add to this the offset of the first method of the interface in the VMT of MyObject (known at compile time) - Store the result in the corresponding "field" of "PointerToInterface" > PointerToInterface^.MyMethod; - Pass the first "field" of "PointerToInterface" as "Self" parameter - Get the right "field" of "PointerToInterface" (i.e. the field corresponding to the interface that MyMethod belongs to -- there can be several matching interfaces (due to inheritance between interfaces), in this case it doesn't matter which one is used) - Add to this the offset of MyMethod relative to the first method of this interface within the VMT -- this is constant for any type that implements this interface. - Dereference the result and do the call (In the case that "PointerToInterface" points not also to interface(s), but also to a type T, and that MyMethod is a method of T, one could call MyMethod more easily through T's VMT, of course.) > PointerToObject:= @MyObject; > PointerToObject^.MyMethod; Just as it does now. Pointers to object types are not affected in any way. > 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. Just give it a different name then internally (like i-pointer, or here i1-pointer, i2-pointer, ...). This might help to spot all the places where conversions are necessary (because an i*-pointer can't be accidentally confused with a conventional pointer then). I mean: internally, i-pointers are a completely different data type than pointers. Calling them pointers (and accessing them with ^ and @) is just a syntactical issue, isn't it? > Now we have two of them: The solution with offsets stored in the object is > O(1) as well. (-: Implement both? ;-) I fear it would only increase confusion -- and it seems tricky enough to get one version right at all. I think we should decide for one way. Any opinions? > > 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.) True (it really seems Delphi uses some kind of searching for interfaces...) -- but anyway, I like the "[]" syntax for ObjIDs for normal object types. > > 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, Really -- their IDs must be the very same in a different program run? If so, why? I'm asking just out of curiosity. > > > 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. But I still can't understand why you can't simply use the pointer from the beginning, i.e. when you assign IDs (like "Factor1ID := Factor1^.ID"), you just do "Factor1ID := @Factor1". Then you have the pointer when you need it. Is it that the whole object "Factor1" can change (be reallocated), not only its contents change -- the "aliasing bug"? In this case, I'd use a pointer to a pointer to "Factor1" (like a handle to a memory block) -- this doesn't save space, but would eliminate the need to search for a pointer via an ID, and might be more efficient. But this is getting a bit off-topic for this thread... > 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. Yes, I'd like this very much (via a parent class pointer, and a list of child classes, probably)! And, BTW, there were a few requests in clpb about such a thing which is missing in BP -- so it will be another advantage compared to BP, though not Delphi... :-) After all, replacing "Typeof(V)=Typeof(T)" by "V IS T" is not only shorter, more readable and looks more like a "clean" language, but doesn't break if a descendant of T is used for V. In my experience, there are only few cases where really an exact type match is wanted, usually one would rather include (possible) descendants if one could. > > 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? I don't know about Delphi. This is how Java (and, AFAIR, C++) behaves, and how it should behave (do all checks at compile-time rather than at run-time if possible). > > 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. *): This sounds like a bad design of TV (no surprise to me...). If designed well, changes should only be necessary in relatively few places. Of course, if changes are made to "gpc's TV" to make it more easily adaptable to graphics mode (or whatever), these changes could go into the main distribution. The actual graphics mode changes (which should be rather few then) should go into a separate package. If this doesn't work well (i.e. if many diffs between text and graphics version remain), this might be an indication that TV and TV/graphics are simply different enough to not share the same classes. (And actually, one would hardly ever use objects of both packages in the same program.) So they could be simply two packages with "similar" source then... > What we can do is to patch Turbo Vision for use with GPC and to distribute > the patch. The `GNU patch' program works very reasonably, and 90% of those > who intend to use TV with GPC will be Borland customers who have the TV > source anyway. Probably 100% as soon as there's a "real gpc" TV-like library. > > Part of the reason Borland has not released Turbo Vision into the public > > domain is Turbo Vision remains an important and valuable feature of > > Borland's Turbo Pascal 7.0 for DOS, which is currently available from > > Borland. > > That's a joke? Borland's kind of humour!:-( > Turbo Pascal 7.0 is *dead* because it's no longer supported. > That's one reson why we are working on GPC - a *living* compiler! > What Borland still sells are parts of the corpse ... |~( <shudder> So they adapted to M$ in yet another sense... > And let us work on > something which will make the world forget that TV did ever exist! :-) ...and Borland as well (if they behave like this) -- sad to say so... > I have attempted to compile TVision with GPC, but it lacked to much object > support. ...and x86 real mode assembler support, I suppose... ;-( -- 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: GPM???
by Frank Heckenbach 02 Jun '97

02 Jun '97

Peter Gerwinski wrote: > It's no problem to find `bar.gpi' from `Program Humpta'. However `Module Foo > Implementation' does not explicitly import `Bar', so it does not know where to > find those `(some, identifiers, listed, here)'. To locate them, it looks at > the name of the module, `Foo', looks up `foo.gpm' where `bar' is listed. Now > it can find `bar.gpi' - voila! > > If it looks weird for you, never mind, it does so for me as well. You don't > need to worry about all this unless you want to change from UCSD-style Units > to EP-style Modules. ;-) Just an idea (since I don't like to have too many files around): it might be possible to have one file (with the unit name = file name) in the case of units and two files (one with the module name (= file name?) and one with the interface name) in the case of modules. Not urgent, of course... -- 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: Portability questions (Arrays)
by Frank Heckenbach 02 Jun '97

02 Jun '97

Peter Gerwinski wrote: > > function f(var a:t):integer; > > var > > p:^integer; > > begin > > p:=@a[0]; > > {some loop} > > if {...} then > > begin > > p^:=...; > > inc(p) {is this ok, BTW?} > > end; > > {...} > > f:="offset of p in a" > > end. > > "inc(p)" should work in GPC. You can even do > > for p:= @a [ 0 ] to @a [ n ] do > p^:= ...; The latter doesn't fit into the procedure above, but if "inc(p)" works, fine! > What about intoducing a "difference between pointers" operator which returns > the number of elements they lie apart (as an integer)? > > f:= p - @a [ 0 ]; This would be great! > (Only with (*$X+*), of course.) Of course! -- 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: bpcompat-1.0.zip
by The African Chief 02 Jun '97

02 Jun '97

On Fri, 30 May 1997 16:16:22 +0300 (EET DST) Jukka Virtanen <jtv(a)cc.hut.fi> wrote: >> Does anyone know of any way (including portable C functions) to return >> the total available system memory, and the total free system memory? >> >> Information of this kind would help in making MemAvail() and MaxAvail() >> useful on platforms other than DJGPP. Thanks. >> > > This is kind of system specific, but perhaps you could > try the 'getrlimit' syscall in unix boxes to > get the memory size that a process is allowed to > use. Thanks. Is this available in the unix C libraries? Otherwise, I will just have to leave the functions as they are. 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: bpcompat-1.0.zip
by The African Chief 02 Jun '97

02 Jun '97

On Thu, 29 May 1997 15:41:28 -0400 (EDT) Pierre Phaneuf <pp(a)dilu.ml.org> wrote: >> >Better make their functionality integrated in the units, >> >> I am not sure what this means. If it means writing the code for DOS >> and CRT from the scratch, I wouldn't want to be the one to do that! > >No, but instead of putting the conio.h port with GPC, we could look what >they do in their sources, port it to Pascal and put the port into a >conio.pas unit or directly in the CRT unit... That is what I meant - translating the C sources is not something I would like to do. It would be fraught with difficulties anyway, because presumably, the C sources themselves will be making calls to functions that are platform dependent. >> AFAICS the unix version is not in the DOS version, otherwise I would >> have used it (I tried to use only portable C functions in the SYSTEM >> unit). The problem is that itoa() exists in DJGPP and EMX (and perhaps >> CYGWIN) but not in unix/Linux. If there is a function in the unix/Linux >> C libraries that does the same thing, that function does not exist in >> DJGPP, so it cannot be used there. I cannot see any solution other >> than an IFDEF here! > >It seems the portable way is to use sprintf(), but Peter suggest using >WriteStr() instead, which is standard Extended Pascal, which will work >same both with DJGPP, EMX and Unix! Yes. I first changed it to use sprintf(), then after some correspondence with Peter, I have changed it to use WriteStr() instead. Other amendments include; [1] "_fmode" is now used only if "__MSDOS__" is defined [2] the DPMI stuff is only used if "__DJGPP__" is defined. - which means that MemAvail() and MaxAvail() return zero in other platforms. AFAIK the SYSTEM unit is now totally portable. Does anyone know of any way (including portable C functions) to return the total available system memory, and the total free system memory? Information of this kind would help in making MemAvail() and MaxAvail() useful on platforms other than DJGPP. Thanks. 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

3 3

Re: Turbo Vision copyrights
by Peter Gerwinski 01 Jun '97

01 Jun '97

According to Jan-Jaap van der Heijden: > > This is cut from a message by Robert Hoehne to the DJGPP mailing lists. > Read and weep ;-( Is this about Turbo Vision for C or for Pascal? If it's for C, it would be a catastrophy for RHIDE! If it's for Pascal, it's still sad, but ... According to ... hmmm ... Robert Hoehne or Eric Pesik? > > [...] You may also distribute your own Turbo > Vision patches and bug-fixes so long as it is limited to your own code. > However, you may not distribute the Turbo Vision source code without > permission from Borland. What we can do is to patch Turbo Vision for use with GPC and to distribute the patch. The `GNU patch' program works very reasonably, and 90% of those who intend to use TV with GPC will be Borland customers who have the TV source anyway. > Part of the reason Borland has not released Turbo Vision into the public > domain is Turbo Vision remains an important and valuable feature of > Borland's Turbo Pascal 7.0 for DOS, which is currently available from > Borland. That's a joke? Turbo Pascal 7.0 is *dead* because it's no longer supported. That's one reson why we are working on GPC - a *living* compiler! What Borland still sells are parts of the corpse ... |~( <shudder> Let us hope that they won't take away RHIDE from us! And let us work on something which will make the world forget that TV did ever exist! :-) 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

GPM???
by Peter Gerwinski 01 Jun '97

01 Jun '97

According to Bernhard Tschirren: > > Im using GPC 2.0 (Alpha 9704??) with DJGPP 2.01. I noticed that a unit > creates two files - One witht the extension GPI and another GPM. What is > this GPM? In fact it creates three files: - The `.o' file which contains the implementation part, functions and variables, - the `.gpi' file which contains the pre-compiled interface part, and - the `.gpm' files which serves the only purpose to tell which interfaces are implemented in the Unit. The need for the `.gpm' file arises from Extended Pascal's Modules. In a UCSD-style Unit (like in Borland Pascal), you can always arrange it in a way that a Unit `Foo' - the identifier appearing after `uses' - is located in a file `foo.pas'. With Extended Pascal, you don't include `Module Foo' but some interfaces defined in the module which usually don't have the same name: Module Foo Interface; Exports Bar = (some, identifiers, listed, here); end. This will produce `foo.gpm' and `bar.gpi'. (See the info documentation, section `Extended Pascal' for more about EP Modules.) Another file may contain: Module Foo Implementation; ... This will read `foo.gpm' and `foo.gpi' and produce `foo.o'. To use it in a program, do Program Humpta; Imports Bar; ... It's no problem to find `bar.gpi' from `Program Humpta'. However `Module Foo Implementation' does not explicitly import `Bar', so it does not know where to find those `(some, identifiers, listed, here)'. To locate them, it looks at the name of the module, `Foo', looks up `foo.gpm' where `bar' is listed. Now it can find `bar.gpi' - voila! If it looks weird for you, never mind, it does so for me as well. You don't need to worry about all this unless you want to change from UCSD-style Units to EP-style Modules. ;-) Schoene Gruesse, 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: GPC Exit Bug
by Peter Gerwinski 01 Jun '97

01 Jun '97

Hallo Bernhard, hello everybody! According to Bernhard Tschirren: > > Function ThisIsABug : Integer; > Begin > ThisIsABug := 0; > Exit; > > ThisIsABug := 100; > End; > > Begin > WriteLn(ThisIsABug); > End. > > [...] > > The output is not 0 as expected! It not even 100!!! Looking at the ASM > produced, we can see its one of those nasties left behind by C (RETURN). Indeed! It will be fixed in the next release (perhaps this evening). > Im using GPC 2.0 (alpha 9704?? - Im not sure about the ??, but it might be > 20) with DJGPP (2.01). It holds for any version of GPC which understands `Exit'. > Thank you (EVERYBODY) for creating the greatest development platform in the > world!! Thank you! (-: Be invited to join us in improving GPC. Thanks for reporting the bug! Such feedback is very important - for testing GPC as well as for motivating us to go on. :-) Tschuess 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 01 Jun '97

01 Jun '97

According to Frank Heckenbach: > > I'm briefly describing the situation I have. It's about speed optimization. > [...] > I thought about optimizing it with a pointer like this: > > function f(var a:t):integer; > var > p:^integer; > begin > p:=@a[0]; > {some loop} > if {...} then > begin > p^:=...; > inc(p) {is this ok, BTW?} > end; > {...} > f:="offset of p in a" > end. "inc(p)" should work in GPC. You can even do for p:= @a [ 0 ] to @a [ n ] do p^:= ...; Since all this is a "not very Pascalish" feature of GPC, you must enable it with the (*$X+*) directive. > So "f:=(integer(p)-integer(@a)) div sizeof(a[0])" doesn't seem to work then. > Or are other means of pointer arithmetic available -- or completely other > ways to do it? This wouldn't work in C either because of the same reason (SizeOf ( Pointer ) needn't be the same as SizeOf ( Integer )). How would you solve this problem in C? What about intoducing a "difference between pointers" operator which returns the number of elements they lie apart (as an integer)? f:= p - @a [ 0 ]; (Only with (*$X+*), of course.) 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

Turbo Vision copyrights (fwd)
by Jan-Jaap van der Heijden 01 Jun '97

01 Jun '97

Hello all, This is cut from a message by Robert Hoehne to the DJGPP mailing lists. Read and weep ;-( ---------- Forwarded message ---------- Date: Wed, 21 May 1997 16:43:58 -0800 From: Eric Pesik <epesik(a)corp.borland.com> To: SWright243(a)aol.com, tw543229(a)dutiwy.twi.tudelft.nl, u6ed4(a)wvnvm.wvnet.edu Subject: Borland Turbo Vision Greetings! I apologize for not responding right away. For convenience, I am copying you and two other people who wrote to me personally with Turbo Vision questions. As you know, it is widely believed that Borland has released Turbo Vision into the public domain. Regrettably, that is not true. However, this does not affect the rights or licenses granted to any licensed user of the Turbo Vision product. Obviously, you may write and compile programs using the Turbo Vision libraries, and distribute them in object code form as part of your application. You may also distribute your own Turbo Vision patches and bug-fixes so long as it is limited to your own code. However, you may not distribute the Turbo Vision source code without permission from Borland. Part of the reason Borland has not released Turbo Vision into the public domain is Turbo Vision remains an important and valuable feature of Borland's Turbo Pascal 7.0 for DOS, which is currently available from Borland. If Borland decides to release Turbo Vision into the public domain in the future, (or if Borland releases it under different licensing terms) I will make sure a notice is posted to the Turbo Vision list. I hope this helps clear up any confusion. I know it is not the answer you had hoped for, but if you have any additional questions, please feel free to reply. Eric Pesik BORLAND INTERNATIONAL

1 0

OOP
by Frank Heckenbach 31 May '97

31 May '97

Pierre Phaneuf wrote: > > I agree. Also, I don't like the type-casting bit. But, AFAICS, making > > Load a virtual method (or virtual constructor in the future?) would > > remove all these problems. Since the VMT has been assigned at this point, > > a virtual method can be called without any tricks. > > Yes, that's what I intend to do for the GPC-specific class library, but > for the BPCOMPAT package, the Load method is a constructor, and we have to > be compatible, so... :-( Peter, what about making virtual constructors soon? Should be relatively easy (I hope), just "combining" the properties of constructors and virtual methods? ;-) > > I know that this complicates matters, especially in the base classes, but > > since this is mostly a one-time job, I think it's worth the effort. > > Actually, it simplify things... (IMHO) In the long run, definitely! > > Anything more (e.g. load and store methods) will not be common to all objects > > (e.g. a mouse object probably can't be stored in a stream), so this should be > > introduced in another class (or interface). > > I thought about that, having a direct TObject descendent (TPersistent), > but the problem lied in abstract classes that has descendents that were > streameable and others that aren't. Like say TCollection, which can be a > collection of streameable objects (where you want to implement TCollection > itself as a streamable class) or not. Do we descend TCollection from > TPersistent or TObject? If we descend from TPersistent, what do we do in > case that the TCollection contains non-streamable objects? Perhaps like this: TAbstractCollection(TObject) TCollection(TAbstractCollection) works with TObject's TStreamableCollection(TAbstractCollection,TStreamable) works with TStreamable TObject's This assumes that TStreamable will be an interface, and that type declarations like "TStreamable TObject", consisting of an interface and an object type are allowed -- this should not be much more difficult to implement than interface type variables, see below. TAbstractCollection is an abstract class that implements all the functionality (working on TObjects), but only as protected methods. Most methods of TCollection and TStreamableCollection just call the methods of TAbstractCollection. The introduction of TAbstractClass seems necessary in order to prevent that a TStreamableCollection can be cast into a TCollection -- which would allow inserting non-streamable objects into a TStreamableCollection. I think this is a rather difficult example, but I think with a mechanism like what I described, it can be solved (perhaps there are a few problems left, but they can be solved, too, hopefully). The benefit is that all the checks (if a collection is streamable) can be made at compile time. If collections are implemented "more simply", this check can only be made at runtime, AFAICS, by checking if all members of a collection are streamable (or to allow only collections of streamable objects at all) -- I suppose Borland does it one of these ways!? > I like having my objects "cleaned out", but this is really personal... :-) > I guess no constructor is ok if we don't do anything, but I'd like to keep > this... It's easy to bypass if you don't want to use this... No objections from me, just a question: 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? ... With BP and DO$, it's simple. The question is how much sense such a FillChar makes on any platform. David Fiddes wrote: > Here's a simple example of how Delphi 3.0 implements interfaces. The main > difference between this and what Frank was suggesting is that Delphi 3.0 > doesn't allow and fields in an interface. Perhaps you misunderstood me. The only "fields" allowed in a Java interface are plain constants, which, technically, are no fields, i.e. don't appear either in the object's data or in the VMT. They're just constants that could be declared outside of the interface declaration as well - except for scoping differences (or, more precisely, the need for a qualified identifier to access them outside of the object type's methods). > This is because COM is designed > to work across process and machine boundaries using remote procedure > calls(RPC) but does have support for remote variable calls(if there is such > a thing!) and this is the main reason for using interfaces... Actually, Java is a threaded language, too (and though I think it was not designed for distributed programs, this should be easily possible in Java), so this might have been a consideration there, too. But I think the main goal in Java was to avoid the problems C++ got from MI. > this simple example of a Delphi interface is from a copy of a unit I'm > working on to use MS ActiveScripting. > > the interface bit: > const > SIID_IActiveScriptSiteWindow = '{D10F6761-83E9-11cf-8F20-00805F2CD064}'; I don't understand what this serves for. Perhaps Delphi's interfaces are more than what we're discussing here, i.e. an extension to the object model. It seems to me they're somehow interrelated to some Windoze features... I would object to that, since language features and OS things should be separated, IMHO. OTOH, this might also be the "ObjID" of the interface, used to locate the interface in the VMT, see below. > type > > IActiveScriptSiteWindow = interface(IUnknown) > [SIID_IActiveScriptSiteWindow] What's IUnknown for? I'd prefer simply "interface" for a "top-level" interface, just like "object" for a top-level object. And, in contrast to object types, there is really no need for a "mother of all interfaces", since there's *nothing* (no method, no constant, and of course not the ID) that all interfaces have in common. > You access an interface using the QueryInterface function in the IUnknown > interface from which all interfaces are derived by passing it the > interfaces IID. This partly explains what IUnknown is for, and it reveals something about how Delphi implements all of this. But, AFAICS now, I don't like this, if the programmer has to do extra work to access the interfaces. I'd like to have it transparently, just like in my description of Java, i.e. you can pass (a pointer P to) any object that implements IWhatever to a procedure, and this procedure can call P^.SomeMethod if SomeMethod is a method declared in IWhatever. Of course, this involves some work for the compiler (discussed below), but I still think it's possible to do, and then it's more comfortable to use these interfaces. Peter Gerwinski wrote: > Compatibility to other widely-used compilers and/or well-defined standards > is always desireable as long as it doesn't take away too much time from > more important tasks. ... 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! > As I understand this, the Interface mechanism is MI with the following > requirements: > > * Each object type has one "primary ancestor"; possible other ancestors > are "secondary". Or no "primary ancestor" at all. It can implement some interfaces, but not inherit from some other object type. > * Definition: An object type which does not have data fields, but only > abstract (virtual) methods qualifies as an "interface". > > * The primary ancestor of an object may be any object; secondary > ancestors must be interfaces. 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. > This implies: > > * MI among interfaces works without restrictions. Right. > * Instances of interfaces are useless. Not even allowed. (Cf. below about abstract object types.) > * You cannot inherit data fields and function bodies via MI. No, you can't (only from the "primary ancestor"). > * MI does no more cause all those catastrophies as it would be the case > with unrestricted MI among "real" objects. Correct. :-) (Of course, there can be conflicting method identifiers with interfaces that are implemented, but these should simple generate "duplicate identifier" errors.) > Making these rule obligatory, it would be save to introduce MI into GPC, > thus introducing interfaces without needing another keyword. (Just an > idea.) However since Delphi seems to have interfaces, we should use their > syntax rather than inventing another one. (Just another idea.) 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). 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. - It's not inherited. If not explicitly declared in a new type, its value will be 0. (Perhaps with a warning if the parent type has an ObjID<>0.) - The compiler checks that no two types or interfaces in a program have the same ID (except 0, of course). - For convenience, it can be declared in "[]" as above. This removes all needs for class registration, and perhaps solves some problems with interfaces. I think I like that! > (* 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? ... > > 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! 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. > > First of all, since interfaces can't be instantiated, such variables or > > parameters must be pointers (or var parameters). In Java, this is implied, > > since *all* object variables are pointers. > > 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. > > - 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? 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 ... 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. > > - The VMT must contain information about all interfaces that are implemented > > together with the addresses of their methods. However, since different > > object types can implement different interfaces, and one type can > > implement more than one interface, I can't think of a method that doesn't > > involve some kind of searching (searching the wanted interface out of > > possibly many interfaces). > > 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. ;-] > 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... ;-) > I agree. Calling virtual methods works quite fast as it is implemented > now. If having interfaces (or MI in general) would slow this down, I would > vote against it. Me too. > 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! 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! 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... > > 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. > 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. 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.) > > 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? 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). If you mean in a stream: the type information will be stored by the ObjID, which will be converted to a VMT link by the stream loader, so there's also no need for the object (instance) ID to contain any type information. Am I missing something? > > I assume "pure virtual" is the same as "abstract" methods!? > > I.e., any class that has at least one abstract method can't be instantiated. > > Is it correct like that? > > > Type > MyObj = object > Procedure Foo; abstract; > end (* MyObj *); > > MySecondObj = object ( MyObj ) > Procedure Foo; virtual; > end (* MySecondObj *); Of course, MyObj could also declare some non-abstract methods and/or fields (otherwise, it could also be an interface). > `MySecondObj.Foo' must be implemented, and `MyObj.Foo' mustn't? Right. > 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. 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! 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. > 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. > 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). > If Assigned ( p ) then begin > If p^.Name = 'CHIEFDIALOG' then { blah blah } better: If Typeof(p^) = Typeof(TChiefDialog) then { blah blah } Removes the need for Name field, also pointer comparisons are (usually) faster than string comparisons. > 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. > > 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.) > Saving > and storing things for another - the objects themselves, the state of > the desktop, the whole environment in which the program is running, > etc. See above (my reply to Peter). > >> >BTW: Would it be possible at all? Doesn't TObject refer to TStream? > >> No, it doesn't. In bpcompat, TObject has a "Load" constructor that takes > >> a TObject parameter. > > > >But doesn't it have to refer to the stream somehow? Do you type-cast the > >parameter into a stream > > 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? (If Load is going to be a virtual method or virtual constructor later, it has to be declared at a base type (or interface), but not in TObject.) > >> That assumes that you already know the object and its address. > > > >If you used the address everywhere you use the ID now, you would know, > >wouldn't you? > > SelfID can be accessed at random - e.g., through a loop. You can't > do that with addresses. Why not? I suppose you're looping through an array of IDs, right? You can loop through an array of pointers as well. > >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? (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. > 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? With the changes above, you would already have the pointer instead of the ID 5, so this function call would even get superfluous. If you mean "give me the pointer to the fifth object [of whatever]", the function call would stay the same, of course. > Like I said, OBJECTS.PAS is a cannibalised form of the main objects > unit in another project - a portable class library ( BP 7.x, Delphi 1 and > Delphi 2) - viz - using only pure Pascal and the Windows API - no OWL, > and no VCL. Well, BPs objects are not very much standard or "pure Pascal", BTW! But you could do what I just said with BP as well. > 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! Well, interfacing the model that we'll develop to Windoze might be some additional work then, but this shouldn't stop us from designing gpc well. > >Right, everything that *every* object should have, not everything that *some* > >objects should have. E.g. handles: not every object has a handle, so it should > >not be in the base class. If in a windowing system, every instance of TWindow > >and its childs will have a handle, then Handle should be a field of TWindow. > > Let's put it this way. If I declare; "Var p : pObject", I would like to be well assured > that p^ will always have a Handle, a Name, and a SelfID. I can then use p in any > number of situations, without having to declare another pWindow just to get > something that has a Handle. I can find out the TYPE of p by its Name. No, you can find out the type of p by checking Typeof(p^). After all, the basic operations of microprocessors work on numbers, not on strings, and we should try to stick to that. In other words: strings (like names) are there for interfacing the computer to humans, but (usually) not for internal purposes of the computer, IMHO. (If the others decide otherwise, this will mean that ObjID becomes a string instead of a number, well ok, then this would be in TObject.) SelfID: see above -- the address suffices. Handle: No! Not every TObject has a handle. Actually, I think, in a UI that's served within the program itself (like TV - in contrast to windowing systems), you don't need any handles at all. The SelfID, and therefore the address, does all you need, doesn't it? AFAIS, Borland's TV doesn't use handles. So again, if you are in an environment (like Windoze) where some objects have handles, and you have a situation where you want to do something with the handle of an object, you declare the variable (or parameter) of an appropriate type that has a handle, but not the base class (TObject), and certainly not a class that will be used in other environments, too. (Otherwise, soon TObject would probably include things like a file name, an URL, a creation/modification/access date/time, perhaps access rights, the address of an X server, terminal settings and whatever more...) > >> They could all have a Name, a SelfID, a Parent, and a Child. > > > >Do you mean a name/ID/parent/child of the *class*, or of the *instance*? > > Of the class. > > >In the former case, I agree (except for the name, which IMHO usually isn't > >needed at runtime, see above), > > I have read all the discussion about VMTs. I still prefer this; > If p^.Name = 'TCHIEF' then .... The object constants (stored in the VMT) should be accessible like this. (At least that's why I have in mind.) Except that Name will not be automatically defined (only in Delphi-mode or if explicitly switched on). 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; ... > >Why not simply derive one (or several) classes from it with whatever you > >want? That would be in the spirit of OOP (not to change existing classes, > >but just derive new ones from them). > > 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. Pierre Phaneuf wrote: > Yes? Simply use the address instead of the ID, will do exactly the same > thing. > > [...] > > Hmm... Could you give me an example of an integer (or better yet, the > instance pinter) not being flexible enough? And how do you plan to do your > string system?? > > [...] > > A wide need for this information??? Just give me a single example where > knowing the class name at runtime would be useful, not taking into account > debugging purposes, where you could/should use a debugger or normal > constants. > > [...] > > MyObj.Foo shouldn't be implemented, exactly. But having a call to > MyObj.Foo generate a run-time error would be exactly like how it is done > now in BP. It is simple: a class containing one or more "abstract" methods > shouldn't be allowed to be instantiated. Presently you *can* instantiate a > TStream object, but this will yield a run-time error as soon as one of the > abstract method are called (because their implementation consist of a call > to Abstract, which has a call RunError()). If TStream would use an > "abstract" keyword to indicate its abstract methods, it wouldn't even be > allowed to be instantiated. The compiler would yield a compile-time error > where possible (so that code instantiating TStream wouldn't even compile) > and generate a run-time error where the illegal instantiation couldn't be > detected at compile-time. (with our AssignType() function for example) Pierre, I guees people are starting to think we're the same person writing from two different accounts... ;-) -- 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: Portability questions (Arrays)
by Frank Heckenbach 31 May '97

31 May '97

Peter Gerwinski wrote: > > (Is it generally allowed to cast a pointer into an integer, > > in the first place?) > > I just found out that on the DEC Alpha a pointer has 8 bytes, while > an integer has 4. Good that I didn't use this "feature" yet. I'm briefly describing the situation I have. It's about speed optimization. I have the following (simplified): type t=array[0..max] of integer; function f(var a:t):integer; var i:integer; begin i:=0; {some loop} if {...} then begin a[i]:=...; inc(i) end; {...} f:=i end. I thought about optimizing it with a pointer like this: function f(var a:t):integer; var p:^integer; begin p:=@a[0]; {some loop} if {...} then begin p^:=...; inc(p) {is this ok, BTW?} end; {...} f:="offset of p in a" end. So "f:=(integer(p)-integer(@a)) div sizeof(a[0])" doesn't seem to work then. Or are other means of pointer arithmetic available -- or completely other ways to do it? I know that all of this is not very "Pascalish", but this routine requires the utmost speed possible, so I tried to elimitate the need for an array lookup, and to save one register (only p instead of i and the address of a) -- this really does make a difference since the rest of the loops uses some more variables. I hope I don't have to convert the routine into C to get the best speed. -- 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

GPM???
by Bernhard Tschirren 31 May '97

31 May '97

Im using GPC 2.0 (Alpha 9704??) with DJGPP 2.01. I noticed that a unit creates two files - One witht the extension GPI and another GPM. What is this GPM? Bernhard Tschirren ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

GPC Exit Bug
by Bernhard Tschirren 31 May '97

31 May '97

My dodgy programming was once again not working! After a couple of hours debugging I found that the problem was not mine, but a slight 'MINOR' bug in GPC. Take a look the the code below. Function ThisIsABug : Integer; Begin ThisIsABug := 0; Exit; ThisIsABug := 100; End; Begin WriteLn(ThisIsABug); End. Im using GPC 2.0 (alpha 9704?? - Im not sure about the ??, but it might be 20) with DJGPP (2.01). The output is not 0 as expected! It not even 100!!! Looking at the ASM produced, we can see its one of those nasties left behind by C (RETURN). Thank you (EVERYBODY) for creating the greatest development platform in the world!! ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: OOP
by Peter Gerwinski 30 May '97

30 May '97

According to Frank Heckenbach: > > > >I'm probably missing something - but isn't the address of an object a > > >"unique ID"? (One that makes it very easy to "locate" the object... ;-) > > As I said, I might be missing something, but I still don't know what it is... > > > That assumes that you already know the object and its address. > > 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. 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. However numbers are not flexible enough to achieve this functionality with reasonable effort. I will use strings for this purpose - as explicit data fields of some object relatively close to the root of my object hierarchy. > > And, suppose that, for some obscure reason, > > I suddenly wanted to locate all currently active object instances and/or > > their parents (if any), how would I do this using addresses? - but I could > > do this with a loop through the SelfIDs. > > 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. > I think, if some program for any reason does need this information, it could > declare object constants (if implemented), or methods (in the meantime) that > provide this information explicitly, but unless there's a wide need for this > information (which I can't see), I don't think it should be included > automatically. Although I think there is wide need for this information, I think it's the choice of the programmer to include it, so it should not be included automatically ... except perhaps when emulating Delphi, but then it's optional, too. > I assume "pure virtual" is the same as "abstract" methods!? > I.e., any class that has at least one abstract method can't be instantiated. Is it correct like that? Type MyObj = object Procedure Foo; abstract; end (* MyObj *); MySecondObj = object ( MyObj ) Procedure Foo; virtual; end (* MySecondObj *); `MySecondObj.Foo' must be implemented, and `MyObj.Foo' mustn't? And calls to `Foo' in instances of `MyObj' would yield a run-time error? > Many "un-definable" Pascal procedures could be defined with overloading > and/or optional parameters. Both is possible to do in Pascal, and I hope, > gpc will have them sometime. My first attempt to implement that failed :-(, but I keep trying! 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: OOP
by Peter Gerwinski 30 May '97

30 May '97

According to Pierre Phaneuf: > > I was thinking that it would be nice to have this in GPC only because > Delphi had it, without even thinking *how* it could be useful. Compatibility to other widely-used compilers and/or well-defined standards is always desireable as long as it doesn't take away too much time from more important tasks. > Now that I > spent some thoughts on this, it's no longer such a good feature to have... > Unnecessary bloat IMHO... If such a feature has disadvantages, it must be optional, e.g. `--store-object-names', and switched ON in Delphi compatibility mode. > > This would indeed be a much better way than Borland's "abtract method" that > > causes a runtime error (again, IMHO, a failure by Borland)! > > Yes, exactly! So I could remove the "Abstract" method (did you receive my > CLASSES.PAS?) from TObject. Not from `objects.pas' in BPcompat, but from your more general class library. 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]

2 1

Re: GPC platforms
by The African Chief 30 May '97

30 May '97

On Thu, 29 May 1997 14:03:05 +0300 (EET DST) Jukka Virtanen <jtv(a)cc.hut.fi> wrote: > >> >> Is it possible to tell which GPC platform and version is being used? >> >> [...] >> >> This would really help in writing portable code. What do you think? > > Please check what gpc (gcc) defines now in your system. > > This is most easily done by creating an empty file, say > foo.p, and compiling it with the '-v' option. In a unix > system, you can do this with: > > # touch foo.p > # gcc -v foo.p > > At least in the version I compiled yesterday for the Alpha, > the defines are: > >/v/dunix40_alpha/gnu/gcc/2.7.2.1/lib/gcc-lib/alpha-dec-osf4.0/2.7.2.1/gpc-cpp >-lang-pascal -v -nocharescape -undef -D__GNUC__=970528(2 -D__GPC__=970528(2 >-D__GNUC_MINOR__=7 -D__unix__ -D__osf__ -D__alpha -D__alpha__ -D_LONGLONG >-D__SYSTYPE_BSD__ -D_SYSTYPE_BSD -D__unix -D__SYSTYPE_BSD -Asystem(unix) >-Asystem(xpg4) -Acpu(alpha) -Amachine(alpha) -D__LANGUAGE_C__ -D__LANGUAGE_C >-DLANGUAGE_C /tmp/foo.p /tmp/ccaagopa.i >GNU CPP version 970528(2.7.2.1) > > So, it seems that the __GPC__ define at least will get screwed > up, if it is generated like it is now. I just tried this under DJGPP. This is what I got; gpc version 2.0(2.7.2.1) c:/gpc/bin\gpc-cpp.exe -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=0(2 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__DJGPP__=2 -D__DJGPP_MINOR__=1 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=1 oka.pas c:\temp\ccbaaaaa GNU CPP version 2.0(2.7.2.1) (80386, BSD syntax) I see that "__unix__" is defined. This is very worrying. If I do {$ifdef __unix__} the code gets compiled (why? I am using DOS, not unix). If I do {$ifdef __UNIX__} the code (rightly) does not get compiled. So, this IFDEF thing is case sensitive. Isn't case sensitivity one of the C problems that we are trying to move from? > Also, I'd recommend in using the same definitions as > are defined for the GCC for the same host. Why add new ones? For the simple reason that we may not know all the definitions. I only know the definitions for DJGPP - and I am trying to produce a portable BP-compatible SYSTEM unit. How do I know what all the other GCC platforms define? What if they change? I would like us to have GPC-specific defines (at least, to identify the various GPC platforms), which are in the GPC documentation. I am surprised to find that "__unix__" is defined on my DJGPP system. I now find that it is also defined on your Alpha system (and probably every other GPC platform?). I would like us to define something more reliable than this, so that it is easier to write portable code using IFDEFs. In the meantime, can somebody please send a copy of the defines on; EMX, Linux, Solaris ? Thanks! 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

2 1

Re: OOP
by The African Chief 30 May '97

30 May '97

On Fri, 30 May 1997 00:35:54 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: >The African Chief wrote: > >> >BTW: Would it be possible at all? Doesn't TObject refer to TStream? >> No, it doesn't. In bpcompat, TObject has a "Load" constructor that takes >> a TObject parameter. > >But doesn't it have to refer to the stream somehow? Do you type-cast the >parameter into a stream Actually, the Load constructor in TObject does nothing at all. >> >I'm probably missing something - but isn't the address of an object a >> >"unique ID"? (One that makes it very easy to "locate" the object... ;-) > >As I said, I might be missing something, but I still don't know what it is.... See my earlier post of today. >> That assumes that you already know the object and its address. > >If you used the address everywhere you use the ID now, you would know, >wouldn't you? SelfID can be accessed at random - e.g., through a loop. You can't do that with addresses. >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. So, I could really just do something randomly like this; p := InstanceFromSelfID ( 5 ); If p <> NIL then ..... Although of course, you wouldn't want to do that. >I'm really trying to understand what you do with these IDs! Like I said, OBJECTS.PAS is a cannibalised form of the main objects unit in another project - a portable class library ( BP 7.x, Delphi 1 and Delphi 2) - viz - using only pure Pascal and the Windows API - no OWL, and no VCL. 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 hope, it's not only the (bad, IMHO) tendency of Windoze to use "untyped" >handles for each and everything - that might not matter much in C (where >everything is int anway - well almost...), but I think in Pascal we should >try to keep as much typed information (e.g. typed pointers) as possible. Hmm ... >> A purely personal thing, perhaps. If I did it my own way, without any >> preconceived notions, I would have an ancestor object which would >> contain everything that I think every object should have. > >Right, everything that *every* object should have, not everything that *some* >objects should have. E.g. handles: not every object has a handle, so it should >not be in the base class. If in a windowing system, every instance of TWindow >and its childs will have a handle, then Handle should be a field of TWindow. Let's put it this way. If I declare; "Var p : pObject", I would like to be well assured that p^ will always have a Handle, a Name, and a SelfID. I can then use p in any number of situations, without having to declare another pWindow just to get something that has a Handle. I can find out the TYPE of p by its Name. >> > I really don't see what a TWindow object and a >> >TString object has in common that should be in TObject! >> >> They could all have a Name, a SelfID, a Parent, and a Child. > >Do you mean a name/ID/parent/child of the *class*, or of the *instance*? Of the class. >In the former case, I agree (except for the name, which IMHO usually isn't >needed at runtime, see above), I have read all the discussion about VMTs. I still prefer this; If p^.Name = 'TCHIEF' then .... >> >BP didn't set that >> >trend BTW. The Smalltalk anscestor object doesn't do *ANYTHING*. >> >> The first thing I would do to it is to change that omission ;) > >Why not simply derive one (or several) classes from it with whatever you >want? That would be in the spirit of OOP (not to change existing classes, >but just derive new ones from them). 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. Whew! Now to go home to my wife ;-) 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 Peter Gerwinski 30 May '97

30 May '97

According to Frank Heckenbach: > > (Is it generally allowed to cast a pointer into an integer, > in the first place?) I just found out that on the DEC Alpha a pointer has 8 bytes, while an integer has 4. 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: Interfaces (Was: Multiple inheritance)
by David Fiddes 30 May '97

30 May '97

>Those are registry entries. Delphi compiles this code into an OLE >control which is uniquely identified by this ID. They aren't registry entries...they just have the same format..i.e. 128 bit unique numbers It's NOT just for the generation of OLE controls which I agree is highly platform specific... Interfaces just allow you to expose the many faces of a binary(not source) object and do it in an easy to program fashion....It's all possible with GPC as it stands it just take 3 times as long. D/COM is growing in platform support(Win, Mac UNIX) (you could support it on an embedded system eventually) but it's not the only use of interfaces...you could use them to write your own OOP OS if you wanted, using nothing more than the defintion of IUnknown... >Anyway, all of this is Windoze-only code. Absolutely not. It's the first/only genuinely good & platform independant idea to come out of MS..make you wonder who they stole it from.... >Considering the platform-independant spirit of GPC, this is *not* the way >to go, IMHO. Perhaps it's not. There aren't that many folk using this kind of stuff yet for anything other than Windows but that's because they haven't twigged yet... Dave Dave Fiddes, CALM Software Production Officer Department of Mathematics, Heriot-Watt University, Edinburgh email D.J.Fiddes(a)hw.ac.uk - Tel: 0131-451-3251

1 0

Re: Interfaces (Was: Multiple inheritance)
by Peter Gerwinski 30 May '97

30 May '97

According to David Fiddes: > > Here's a simple example of how Delphi 3.0 implements interfaces. The main > difference between this and what Frank was suggesting is that Delphi 3.0 > doesn't allow and fields in an interface. This is because COM is designed "and fields"? (Is the "and" superfluous?) What's "COM"? Sorry, but I don't understand. > to work across process and machine boundaries using remote procedure > calls(RPC) but does have support for remote variable calls(if there is such > a thing!) and this is the main reason for using interfaces... You mean: "does *not* have support ..."? > const > SIID_IActiveScriptSiteWindow = '{D10F6761-83E9-11cf-8F20-00805F2CD064}'; > > > type > > IActiveScriptSiteWindow = interface(IUnknown) > [SIID_IActiveScriptSiteWindow] > > function GetWindow( out phwnd : HWND ):HResult; stdcall; > function EnableModeless( fEnable : boolean ):HResult; stdcall; > end; If I understand this right, the syntax is Type <name> = interface ( <parent interfaces> ) [ <string constant> ] <method declarations> end; What does the string constant serve for? Any idea how the produced code looks like? (It's trivial to make GPC to accept the above source, but probably nontrivial to make it output something reasonable.;-) 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]

2 1

Re: [q] Unit example ?
by Peter Gerwinski 30 May '97

30 May '97

According to Patricio Domingues: > > Being a newbie in GPC use, I'm looking for a GPC unit example, so I can > conceal some C functions interface in this unit. Unit SampleUnit; Interface Procedure Puts ( SomeString: CString ); C; Implementation (* empty *) end. Program Test; uses SampleUnit; begin Puts ( 'OK' ); end. You can find more about this in the GPC FAQ, available in the `contrib' subdirectory on ftp://kampi.hut.fi/jtv/gnu-pascal/ or online at http://home.pages.de/~gnu-pascal/gpc-faq.html. 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: Interfaces
by Peter Gerwinski 30 May '97

30 May '97

According to Frank Heckenbach who cites "Java in a Nutshell": > [...] > While an 'abstract' class may define some 'abstract' methods and some non- > 'abstract' methods, all the methods defined within an interface are > implicitly 'abstract'. [The 'abstract' keyword can, but doesn't have to, be > omitted.] [Note: In Java, all methods are what we call virtual.] > [...] > > So what can we do with an interface? Just as a class 'extends' [is derived > from] its superclass, it also optionally 'implements' an interface. > 'implements' s a Java keyword that can appear in a class declaration > following the 'extends' clause. 'implements' should be followed by the name > of the interface that the class implements. In order to implement an > interface, a class must first delcare the interface in an 'implements' > clause, and then it must provide an implementation (i.e. body) for all of > the 'abstract' methods of the interface. > > [...] As I understand this, the Interface mechanism is MI with the following requirements: * Each object type has one "primary ancestor"; possible other ancestors are "secondary". * Definition: An object type which does not have data fields, but only abstract (virtual) methods qualifies as an "interface". * The primary ancestor of an object may be any object; secondary ancestors must be interfaces. This implies: * MI among interfaces works without restrictions. * Instances of interfaces are useless. * You cannot inherit data fields and function bodies via MI. * MI does no more cause all those catastrophies as it would be the case with unrestricted MI among "real" objects. Making these rule obligatory, it would be save to introduce MI into GPC, thus introducing interfaces without needing another keyword. (Just an idea.) However since Delphi seems to have interfaces, we should use their syntax rather than inventing another one. (Just another idea.) (* Hmm ... the above rules for "careful use of MI" could be useful for *) (* C++ programmers ... perhaps we should tell them? :*) > Concerning a possible implementation in gpc: > > 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. > First of all, since interfaces can't be instantiated, such variables or > parameters must be pointers (or var parameters). In Java, this is implied, > since *all* object variables are pointers. Do you mean: If an object implements an interface (in Java sense) it must always be accessed through a pointer? If so, why? > But such a pointer must point to the actual object and to the methods > declared in the interface. Since different object types can implement the > same interface, those methods will not always be at the same VMT offset. > However, it is possible to guarantee that all methods of one interface > are at consecutive VMT offsets (in the order they're declared in the > interface). (*, see below) > > So one needs the VMT offset of the interface's first method. > > I can see (at least) two solutions: > > - 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. > - The VMT must contain information about all interfaces that are implemented > together with the addresses of their methods. However, since different > object types can implement different interfaces, and one type can > implement more than one interface, I can't think of a method that doesn't > involve some kind of searching (searching the wanted interface out of > possibly many interfaces). That's the problem why I initially asked about MI. Does anybody know how C++ solves that problem? Or Java? Or Delphi? > So this is basically a speed vs. size tradeoff. For most applications, > I think, speed is to be favoured (and 32 bit programming favours speed, > anyway), so I'd prefer the first solution. I can't see a solution without > a need of either searching or additional data *per variable* (whereas > additional data per VMT wouldn't matter so much). I agree. Calling virtual methods works quite fast as it is implemented now. If having interfaces (or MI in general) would slow this down, I would vote against it. 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. :-(-: Yours, 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

[q] Unit example ?
by Patricio Domingues 30 May '97

30 May '97

Hi, Being a newbie in GPC use, I'm looking for a GPC unit example, so I can conceal some C functions interface in this unit. Can anyone send me a unit example ? Thanks, Patricio.

1 0

Re: Interfaces (Was: Multiple inheritance)
by David Fiddes 30 May '97

30 May '97

Hi, Here's a simple example of how Delphi 3.0 implements interfaces. The main difference between this and what Frank was suggesting is that Delphi 3.0 doesn't allow and fields in an interface. This is because COM is designed to work across process and machine boundaries using remote procedure calls(RPC) but does have support for remote variable calls(if there is such a thing!) and this is the main reason for using interfaces... this simple example of a Delphi interface is from a copy of a unit I'm working on to use MS ActiveScripting. the interface bit: const SIID_IActiveScriptSiteWindow = '{D10F6761-83E9-11cf-8F20-00805F2CD064}'; type IActiveScriptSiteWindow = interface(IUnknown) [SIID_IActiveScriptSiteWindow] function GetWindow( out phwnd : HWND ):HResult; stdcall; function EnableModeless( fEnable : boolean ):HResult; stdcall; end; a class that implements that interface: THostSite = class(TInterfacedObject, IActiveScriptSite, IActiveScriptSiteW indow) public Shell : THostShell; constructor Create( pshell : THostShell ); destructor Destroy; override; <code snipped> {** IActiveScriptSiteWindow **} function GetWindow( out phwnd : HWND ):HResult; stdcall; function EnableModeless( fEnable : boolean ):HResult; stdcall; end; The TInterfacedObject is the base object for the class and the IActiveScriptSite and IActiveScriptSiteWindow are interfaces it supports. You access an interface using the QueryInterface function in the IUnknown interface from which all interfaces are derived by passing it the interfaces IID. Hope this is of some interest. Sorry about the formatting of the code...I foolishly installed a beta of MS Outlook Express which doesn't like to put spaces at the start of a line occasionally.... Dave Dave Fiddes, CALM Software Production Officer Department of Mathematics, Heriot-Watt University, Edinburgh email D.J.Fiddes(a)hw.ac.uk - Tel: 0131-451-3251

1 0

Re: OOP
by Frank Heckenbach 30 May '97

30 May '97

David Fiddes wrote: > From: Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> > <snip> > >Would an ID of 8 bytes matter, i.e. are there any stream files where > >4 additional bytes per object would matter? > <snip> > > Why not make them 16 bytes? Sounds excessive maybe but that's how big a > Globally Unique IDentifier (GUID)(or more pretensiously a Universally > Unique IDentifier (UUID)) is...128bits....and there's a stanard for > generating them...and anyone with a windows machine has an implementation > of that(and the Mac and some UNIX boxes too). Upwardly comaptible with > Microsofts Component Object Model(COM) and I'm sure the likes of CORBA use > them too... Is this a standard set by M$? If so, I'd only vote for using it, if it (unlike most M$ "standards") - was openly documented, - was not subject to change at M$'s decision, and - can be used for purposes like ours without possibly conflicting with other (future) uses If this is so, I'd like to know more about these IDs. The African Chief wrote: > >BTW: Would it be possible at all? Doesn't TObject refer to TStream? > No, it doesn't. In bpcompat, TObject has a "Load" constructor that takes > a TObject parameter. But doesn't it have to refer to the stream somehow? Do you type-cast the parameter into a stream (which I wouldn't like, since IMHO type-casting should be avoided wherever possible - it's the "goto" of data structures), or did you implement some of a stream's properties within TObject (which I also don't like, see the discussion about handles)? Sorry for asking, but I don't have bpcompat at hand, and I can't imagine another way... > >I don't know all the details here, but isn't it possible to have a > >TWindow(TObject) with Handle being a field of TWindow, and this function > >returning a PWindow? This would seem natural to me. > > Yes, that is possible. But I don't think it does any harm to have the Handle > in TObject instead. Perhaps not (besides wasting 4 bytes...), but I only know from my own experience that I did sometimes regret thoughts like that. Therefore, I'd prefer to think about classes very exactly, especially about such base classes. And again, what's the disadvantage of putting Handle into another class? > Perhaps. But there are many times when I have wished that certain > things existed in BP's TObject and TWindowsObject. Making a > descendant object is fair enough, but it would have been a lot easier > for me if the things were in the ancestor. Easier perhaps, at least at first sight. But when many people use a class library and change it like that, things can get very complicated soon. It is a bit more work to create a more detailed class hierarchy and to introduce all the fields at the "right" place, but I think in the long run, it's worth the effort - and it's more in the spirit of OOP, as I understand it. > >I'm probably missing something - but isn't the address of an object a > >"unique ID"? (One that makes it very easy to "locate" the object... ;-) As I said, I might be missing something, but I still don't know what it is... > That assumes that you already know the object and its address. If you used the address everywhere you use the ID now, you would know, wouldn't you? > If you > already know it, there would be no point trying to locate it again. That's what I meant by "very easy to locate"... > Also, > there are a whole load of things that you can do with integers that you > cannot do with addresses. Yes, but what do you need to do with IDs? AFAICS, one only needs to compare them (for equality, not for greater/less), and this can be done with addresses. > And, suppose that, for some obscure reason, > I suddenly wanted to locate all currently active object instances and/or > their parents (if any), how would I do this using addresses? - but I could > do this with a loop through the SelfIDs. 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? I'm really trying to understand what you do with these IDs! I hope, it's not only the (bad, IMHO) tendency of Windoze to use "untyped" handles for each and everything - that might not matter much in C (where everything is int anway - well almost...), but I think in Pascal we should try to keep as much typed information (e.g. typed pointers) as possible. Pierre Phaneuf wrote: > > Then it would have to be in the GPI file. Much effort. I think the few > > bytes we can save like that (Just those for the strings plus one pointer > > in each VMT) are not worth it, but perhaps somebody else wants to try > > himself on this problem? ;-) > > This is totally optional to me, and thinking more about it, I was > wondering of what use having the symbol name of an object at runtime... I'm also wondering! I never used Delphi, so I don't know what use it has there. But from my experience, I don't know any case where this is needed - except debugging, of course, but that's another story. I think, if some program for any reason does need this information, it could declare object constants (if implemented), or methods (in the meantime) that provide this information explicitly, but unless there's a wide need for this information (which I can't see), I don't think it should be included automatically. > > (* I suggest to define a pointer to a procedure like the constructor *) > > (* with an *explicit* `Self' parameter, to cast `LoadPtr' to it and *) > > (* then call it. *) > > Its the explicit part I'm trying to avoid... I guess this part will be > compiler dependent, but should be among very few (with the TObject.Init > constructor). I agree. Also, I don't like the type-casting bit. But, AFAICS, making Load a virtual method (or virtual constructor in the future?) would remove all these problems. Since the VMT has been assigned at this point, a virtual method can be called without any tricks. > Also note that Java has been widely > recognized as "C++ as it should have been" (by Bjarne Stroustrup among > others, the designer of C++), and Java *doesn't* have multiple > inheritance. :-) So, let's make "BP objects as they should have been"! :-) > For instance, I tried to make my class as much object-oriented as > possible, free of any procedures. For example, Abstract has been made a > method of TObject and a similar NoStream method has been added to prevent > streaming of non-streamable objects (this is very quite not final, > susceptible to removal). Perhaps "streamability" would be a good choice for an interface (with the methods load and store)? > A thing that would be better to have than multiple inheritance would be > pure virtual methods. Would allow me to remove that Abstract method! ;-) I assume "pure virtual" is the same as "abstract" methods!? I.e., any class that has at least one abstract method can't be instantiated. This would indeed be a much better way than Borland's "abtract method" that causes a runtime error (again, IMHO, a failure by Borland)! The African Chief wrote: > No. C++ is clumsy and bloated. However, the problem is that MI is part > of the language definition. If it were to be implemented in GPC, it wouldn't > be part of any definition. It would just be a local extension that could be > ignored by anybody who so wishes. I don't see that having such an > extension is so bad. Some day, someone will want to use it, and it > doesn't help to tell them that they don't need it. Since interfaces are probably easier to implement (see my other mail), and sufficient for most cases (including all that I know), I suggest implementing interfaces first. If then there is a need for MI that really can't be solved with interfaces, it's time to think about adding MI (but actually I'm quite confident this won't be the case). > A purely personal thing, perhaps. If I did it my own way, without any > preconceived notions, I would have an ancestor object which would > contain everything that I think every object should have. Right, everything that *every* object should have, not everything that *some* objects should have. E.g. handles: not every object has a handle, so it should not be in the base class. If in a windowing system, every instance of TWindow and its childs will have a handle, then Handle should be a field of TWindow. I know that this complicates matters, especially in the base classes, but since this is mostly a one-time job, I think it's worth the effort. > What I think > every object should have changes from time to time, and therefore, for > me, it is better to start with more, than with less ;-) As I said above, if many people with different opinions worked on such a class library, it would always be changing. AFAIK, the purpose of OOP is to have some base classes that can be used by everybody, and more special classes built on top of them that implement the needs of different applications. > > I really don't see what a TWindow object and a > >TString object has in common that should be in TObject! > > They could all have a Name, a SelfID, a Parent, and a Child. Do you mean a name/ID/parent/child of the *class*, or of the *instance*? In the former case, I agree (except for the name, which IMHO usually isn't needed at runtime, see above), in the latter case I don't: a string doesn't have a parent or a child or a name (besides the compile-time identifier), and I don't think it usually needs an ID. > >BP didn't set that > >trend BTW. The Smalltalk anscestor object doesn't do *ANYTHING*. > > The first thing I would do to it is to change that omission ;) Why not simply derive one (or several) classes from it with whatever you want? That would be in the spirit of OOP (not to change existing classes, but just derive new ones from them). > And what is the point of have the ancestor then - just for type > compatibility ? Yes - to do things in a typed way that need "Void" or "untyped parameters" otherwise. So it should have only properties that really *every* object has - which, of course, can't be many, merely administrative things like a VMT pointer, perhaps an empty constructor and destructor, and properties of the class like parent class, (perhaps) child classes, (perhaps) implemented interfaces, (perhaps) ID. Anything more (e.g. load and store methods) will not be common to all objects (e.g. a mouse object probably can't be stored in a stream), so this should be introduced in another class (or interface). > >BPs constructor fills the object with zeros for instance. :-) > > Not very useful at all. They might as well not have any constructor > or destructor. Agreed. Since TObject is an abstract class, it really doesn't need a constructor. The destructor is ok, since it's virtual, therefore must be declared at the base class (this allows removing any object with "Dispose(...,Done)"). Peter Gerwinski wrote: > I suggest to forget about the switch and just store a pointer to a string > constant holding the name of the object in the VMT. Since we don't need > to care about a 64k data segment (4GB will be enough for a while), these > few extra bytes are harmless. ...if there's a real need for it. Otherwise I think, compile-time information like identfiers does not belong in the executable (apart from debug info). I think some people wouldn't like their identifiers to be revealed in a program that's distributed without source. > > [...] In general, I'm > > against "magic" things, like the New() function, or the Write()/WriteLn() > > functions (in BP at least, they cannot be implemented using the > > language!). > > So am I. That's one beauty of C: Everything, including `printf' and such, > is user-definable. (Said by someone who is hacking a Pascal compiler because > he cannot stand the ugly syntax of C/C++ ... ;-) Many "un-definable" Pascal procedures could be defined with overloading and/or optional parameters. Both is possible to do in Pascal, and I hope, gpc will have them sometime. New and Write (and so on) are (basically) a syntactical simplification for calling procedures that could have been implemented in Pascal. And this is NOT user-definable in C, it's simply missing there! Printf requires the user to explicitly state all the types, while Write does this automatically, and "p=(*t)malloc(sizeof(t))" is not quite the same as "new(p)". Oh, BTW: "sizeof" is not user-definable in C - so they just made it an operator instead of a function, what a difference! ;-) So don't admire C too much for this... ;-) -- 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

2 1

Re: OOP
by Peter Gerwinski 30 May '97

30 May '97

According to Pierre Phaneuf: > > According to myself (Peter Gerwinski): > > > > I don't like that solution either. It makes units compiled with different > > options *really* incompatible with each other. (Programs using `ClassName' > > will rely on the function returning the correct result.) > > Ok, then make it a program level switch, that doesn't have any effect in > units... But then, do we need it? I suggest to forget about the switch and just store a pointer to a string constant holding the name of the object in the VMT. Since we don't need to care about a 64k data segment (4GB will be enough for a while), these few extra bytes are harmless. > Its the explicit part I'm trying to avoid... I guess this part will be > compiler dependent, but should be among very few (with the TObject.Init > constructor). Whatever we do here, it will be compiler dependent. If we implement some feature into GPC to select a constructor through a VmtLink, we can be sure that no other compiler has this. I do not worry about compiler dependence since all of this is written especially for GPC - and other compilers which claim to be compatible to GPC do not exist yet. I *do* worry about portability between the various platforms GPC runs on. > > > [...] something like SetTypeOf(P, VMTLink)? ;-) > > > > PtrToMyObj^.TypeOf:= TypeOf ( SomeObjectType ); > > Maybe this would be better... But I don't like this very much either... What about AssignType ( MyObj, MyVmtLink ); where MyObj is an object variable (usually a pointer dereference) and MyVmtLink points to the VMT? > [...] In general, I'm > against "magic" things, like the New() function, or the Write()/WriteLn() > functions (in BP at least, they cannot be implemented using the > language!). So am I. That's one beauty of C: Everything, including `printf' and such, is user-definable. (Said by someone who is hacking a Pascal compiler because he cannot stand the ugly syntax of C/C++ ... ;-) 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: Multiple inheritance (Was: OOP)
by The African Chief 30 May '97

30 May '97

On Wed, 28 May 1997 20:46:54 -0400 (EDT) Pierre Phaneuf <pp(a)dilu.ml.org> wrote: >On Wed, 28 May 1997, The African Chief wrote: > >> If it can be done, then it should be done. However, I would advise >> against using it in the RTS or in any UNIT supplied as part of the GPC >> distribution. Let us make it's use completely optional (i.e., people can >> use it in their own programs if they want, but GPC is itself free from it. > >Well, removing GOTO is another thing that could be done. Maybe we >shouldn't do that, but *please*, let's not add multiple inheritance to a >language whose goal is to be the Right Thing and to be simple. Do you know >how many pages there is in the C++ standard? Its something in excess of a >*thousand*. Do we want *that*? No. C++ is clumsy and bloated. However, the problem is that MI is part of the language definition. If it were to be implemented in GPC, it wouldn't be part of any definition. It would just be a local extension that could be ignored by anybody who so wishes. I don't see that having such an extension is so bad. Some day, someone will want to use it, and it doesn't help to tell them that they don't need it. Also note that Java has been widely >> I think this is better than using MI. BP seems to have set the trend to >> have an almost useless ultimate ancestor for an object heirarchy. I >> personally do not agree with that philosophy. > >Why do you disagree? A purely personal thing, perhaps. If I did it my own way, without any preconceived notions, I would have an ancestor object which would contain everything that I think every object should have. What I think every object should have changes from time to time, and therefore, for me, it is better to start with more, than with less ;-) > I really don't see what a TWindow object and a >TString object has in common that should be in TObject! They could all have a Name, a SelfID, a Parent, and a Child. >BP didn't set that >trend BTW. The Smalltalk anscestor object doesn't do *ANYTHING*. The first thing I would do to it is to change that omission ;) And what is the point of have the ancestor then - just for type compatibility ? >BPs constructor fills the object with zeros for instance. :-) Not very useful at all. They might as well not have any constructor or destructor. >The use is in >having the POBject pointer type handy, that can handle *any* objects. You >have a single TCollection that can handle both TWindow objects and TString >objects, even a *MIX* of those! *This* is what TObject is there for, not >have a heap of methods. Ok. Let's just say we have a difference of opinion there! My experience in writing my CHIEFAPP class library has led me to a different conclusion about what an ancestor object should be like. In the end, I suppose that these things are a matter of personal preference! 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

2 1

Interfaces (Was: Multiple inheritance)
by Frank Heckenbach 29 May '97

29 May '97

Peter Gerwinski wrote: > What are these "interfaces"? (Somebody already explained it to me some > time ago, but I have forgotten ... #-) Ok, here are some explanations from "Java in a Nutshell", with some comments by me, and some ideas how to implement them in gpc: "[Text describes a situation that seems to need MI] \footnote{ C++ allows classes to have more than one superclass, using a technique known as 'multiple inheritance'. Multiple inheritance opens up a can of worms, so Java replaces it with what many believe is a more elegant solution. } Java's solution to this problem is called an interface. An interface looks a lot like an abstract class, except that it uses the keyword 'interface' instead of the words 'abstract' and 'class'. [...] While an 'abstract' class may define some 'abstract' methods and some non- 'abstract' methods, all the methods defined within an interface are implicitly 'abstract'. [The 'abstract' keyword can, but doesn't have to, be omitted.] [Note: In Java, all methods are what we call virtual.] A further restriction on interfaces is that any variables declared in an interface must be 'static' and 'final' - that is, they must be constants [ordinary constants, not initialized variables, nor object constants - since ordinary constants don't appear in BP's object type declarations at all, this restriction effectively means there can't be any variables or constants in an interface in gpc, so an interface consists only of declarations of abstract virtual methods (**, see below)]. So what can we do with an interface? Just as a class 'extends' [is derived from] its superclass, it also optionally 'implements' an interface. 'implements' s a Java keyword that can appear in a class declaration following the 'extends' clause. 'implements' should be followed by the name of the interface that the class implements. In order to implement an interface, a class must first delcare the interface in an 'implements' clause, and then it must provide an implementation (i.e. body) for all of the 'abstract' methods of the interface. \footnote{ This is the real difference between multiple inheritance in C++ and interfaces in Java. In C++, a class can interit method implementations from more than one superclass. In Java, a class can inherit actual implementations only from one superclass. It can inherit additional 'abstract' methods [declarations] from interfaces, but it must provide its own implementation of those methods. It is rare, however, to actually be able to use C++ multiple inheritance to inherit useful, non-trivial implementations from more than one class. The elegance and simplicity of Java's interface more than compensate for the inability to inherit implementations from more than one class. } [...] Using Interfaces [...] [Syntax translated to Pascal, tentatively:] Type Drawable=Interface [this wouldn't introduce a new reserved identifer, but I'm not sure if it can be parsed easily.] Procedure Draw(dw:DrawWindow); ['virtual;' or 'abstract;' optionally] [possibly other methods] End; [declaration of type Rectangle that doesn't have a Draw method] DrawableRectangle=Object(Rectangle;Drawable) [in Java this is: public class DrawableRectangle extends Rectangle implements Drawable] x,y:Double; Constructor Init(w,h:Double); Procedure Draw(dw:DrawWindow); virtual; [other methods, destructor] End; [implementation of all methods, constructor and destructor] Var d:^Drawable; r:^Rectangle; dr:^DrawableRectangle; Begin New(dr,Init(2.3,4.5)); d:=dr; r:=dr; dr.Draw; d.Draw; End. [...] [Classes can implement several interfaces ('implements Drawable, Scalable').] [...] Extending Interfaces [...] public interface Transformable extends Scalable, Rotateable, Reflectable public interface DrawingObject extends Drawbable, Transformable public class Shape implements DrawingObject [So there is 'multiple inheritance' between interfaces - which makes no problems!] [...] No 'implements' clause is permitted in an interface declaration. An interface body may not contain any constructors, static class initializers, instance variables, or class methods. [...]" Concerning a possible implementation in gpc: AFAICS, the only thing that really makes problems are variables (or parameters) of interface types. First of all, since interfaces can't be instantiated, such variables or parameters must be pointers (or var parameters). In Java, this is implied, since *all* object variables are pointers. But such a pointer must point to the actual object and to the methods declared in the interface. Since different object types can implement the same interface, those methods will not always be at the same VMT offset. However, it is possible to guarantee that all methods of one interface are at consecutive VMT offsets (in the order they're declared in the interface). (*, see below) So one needs the VMT offset of the interface's first method. I can see (at least) two solutions: - 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). - The VMT must contain information about all interfaces that are implemented together with the addresses of their methods. However, since different object types can implement different interfaces, and one type can implement more than one interface, I can't think of a method that doesn't involve some kind of searching (searching the wanted interface out of possibly many interfaces). So this is basically a speed vs. size tradeoff. For most applications, I think, speed is to be favoured (and 32 bit programming favours speed, anyway), so I'd prefer the first solution. I can't see a solution without a need of either searching or additional data *per variable* (whereas additional data per VMT wouldn't matter so much). (*) If we allow the following inheritance between interfaces A / \ B C \ / D (and I don't see a reason why not), the methods of A will have to be duplicated in D, so that it's possible to "cast" a ^D into a ^B or a ^C. So the "VMT" of D would look like Methods of A \_ "B" New methods of B / Methods of A \_ "C" New methods of C / The two parts "Methods of A" would contain the same information, but since this is only in the VMTs, I don't think it wastes very much memory. I hope I was clear in most things. If not, please ask again. Of course, there will be some "details" left to be solved, but I hope, no major problems. (**) This last thing is a bit off-topic to interfaces, so I put it at the end. Thinking about object constants again, I think there can be "un-virtual" constants, i.e. constants that can be redeclared in child classes, but the parent class will always use their own constants. So, effectively, they're oridinary constants, with the only difference that they're visibility is limited to the object type (applying the usual rules of public/protected/private). These constants don't have to be typed, of course. Also, one can imagine "un-virtual" class variables, very similarly. They should be relatively easy to implement (since the only difference to ordinary constants/variables is the visibility). If this is done, interfaces could contain constants, like in Java. -- 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 The African Chief 29 May '97

29 May '97

On Wed, 28 May 1997 15:46:06 -0400 (EDT) Pierre Phaneuf <pp(a)dilu.ml.org> wrote: >On Wed, 28 May 1997, The African Chief wrote: [...] >Maybe the InstanceFromSelfID is valid (though I'd simply use the instance >pointer as a handle), but (in a Turbo Vision context) only TView should >have a Handle, because it is the first class that can possibly have a >window handle. The InstanceFromHandle would hence return a PView or a >PWindow, which is much more useful, since TView/TWindow has methods for >window manipulation that TObject doesn't even have. Yes, that is correct. The handle is not not necessary in TObject - but I still feel that it does no harm to have it there. >> It has a present use - to be able to locate every object instance by its >> own unique ID. See above. > >The instance pointer is an unique ID, why have another redundant one? Yes, the instance pointer is a unique ID. But this assumes that you know the instance pointer. This will be the case in most situations, but it won't always be the case. And, like I said in another post, there are things that you can do with integers that you cannot do with pointers. 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

2 1

Re: bpcompat-1.0.zip
by The African Chief 29 May '97

29 May '97

On Wed, 28 May 1997 15:54:42 -0400 (EDT) Pierre Phaneuf <pp(a)dilu.ml.org> wrote: >On Wed, 28 May 1997, The African Chief wrote: > >> [1] - the DOS and CRT units are not portable to unix and Linux). This is >> obviously due to the use of functions from DOS.H and CTYPE.H and >> CONIO.H. Can anyone port those units to unix and Linux (or, put another >> way, are there any unix/Linux ports of dos.h, ctype.h and conio.h)? >> Without these, the DOS and CRT units will never port to unix/Linux. > >This is harder. I recommend not using any ports of dos.h, ctype.h and >conio.h (though I know of at least a port of conio.h), because they would >be required to build the units. This wouldn't be a problem if the ports were part of the GPC distribution just as they are with DJGPP (and EMX?). >Better make their functionality integrated in the units, I am not sure what this means. If it means writing the code for DOS and CRT from the scratch, I wouldn't want to be the one to do that! >> [2] the SYSTEM unit is not totally portable - because of "itoa()" which >> I used in the "Str" procedure. itoa() converts an int to a CString. Is there >> a unix/Linux equivalent of this? I can use an IFDEF to link the unix/Linux >> equivalent if "__UNIX__" is defined. > >If there is a Unix equivalent, it could be used both in the Unix version >and the DOS version, no? Would be cleaner... AFAICS the unix version is not in the DOS version, otherwise I would have used it (I tried to use only portable C functions in the SYSTEM unit). The problem is that itoa() exists in DJGPP and EMX (and perhaps CYGWIN) but not in unix/Linux. If there is a function in the unix/Linux C libraries that does the same thing, that function does not exist in DJGPP, so it cannot be used there. I cannot see any solution other than an IFDEF here! 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

2 1

Re: A question for the C wizards... ;-)
by Peter Gerwinski 29 May '97

29 May '97

According to Pierre Phaneuf: > > Here's the answer I got from one of my C wizard friend... :-) > > [...] > > From: stephane.lajoie(a)belairdirect.com > > itoa is in stdlib.h/libc.a for DJGPP. I thought it was ANSI C...? Anyway, I > would suggest sprintf like this: > > sprintf(buf, "%i", i); Why use C when GPC (Extended Pascal) has the same? WriteStr ( Buf, i : FieldWidth ); 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]

2 1

Re: Multiple inheritance
by Peter Gerwinski 29 May '97

29 May '97

According to Pierre Phaneuf: > > If we have to have a MI-like feature, it should be something less > dangerous, like interfaces, not the real thing/poison. What are these "interfaces"? (Somebody already explained it to me some time ago, but I have forgotten ... #-) 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: New gpc-970510 for DJGPP
by Peter Gerwinski 29 May '97

29 May '97

According to Sven Hilscher: > > I had a little problem to use the new info files. I get all the time the > message "node TOP not found". After removing the last line in gpc.inf > (these "end tag table" was doubled) now it works fine... This line was caused by RHIDE. (Somebody should report that bug to Robert ...) 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: GPC platforms
by The African Chief 29 May '97

29 May '97

On Wed, 28 May 1997 19:41:17 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >> Is it possible to tell which GPC platform and version is being used? >> [...] >> This would really help in writing portable code. What do you think? > >I agree in complete. Let's ask the list what they think, but I am almost >sure that everybody will agree. Ok. I am sending this response to the list. >> [...] >> So, can this be done with GPC? It would help with a lot of things, e.g., >> in the SYSTEM unit - so, could we have these pre-defined in GPC; >> __LINUX__ >> __UNIX__ >> __DJGPP__ (or __MSDOS__) >> __EMX__ (or __OS2__) >> __WIN32__ (or __CYGWIN__) >> - depending on which GPC port you are using. > >Since `__MSDOS__' is ambiguous and with EMX one and the same executable >runs on DOS as well as on OS/2 making this a run-time, not a compile-time >decision, I vote for `__DJGPP__' and `__EMX__' rather than `__MSDOS__' >and `__OS2__'. Yes, I agree. >Since I agree with "xxxx" that Windows 95/NT is >not a "win" in the sence of hacker's speech (see `jarg400.info.gz' from >the GNU distribution), but Cygnus is, I'd vote for `__CYGWIN__' rather >than `__WIN32__', although "Win32" is the official name of that API. Yes, "__CYGWIN__" seems fine. >> and you could have; >> __VER20__ >> >> or whatever, depending on the GPC version. > >Here I'd prefer to use the GNU convention and define the `__GPC__' symbol >to be `2' and `__GPC_MINOR__' to be `0'. I am not sure I understand how this works. >This also avoids confusion with Borland Pascal 4.0 once we reach >that version number. There would be no confusion, because BP doesn't include the leading and trailing "__". TP 4.0 would have "VER40" defined. GPC 4.0 would have "__VER40__" defined. 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

3 2

Re: A question for the C wizards... ;-) (fwd)
by The African Chief 29 May '97

29 May '97

On Wed, 28 May 1997 20:04:02 -0400 (EDT) Pierre Phaneuf <pp(a)dilu.ml.org> wrote: > >Here's the answer I got from one of my C wizard friend... :-) >itoa is in stdlib.h/libc.a for DJGPP. I thought it was ANSI C...? Anyway, I >would suggest sprintf like this: > > sprintf(buf, "%i", i); [...] Thanks! 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

New gpc-970510 for DJGPP
by Sven＠rufus.central.de 29 May '97

29 May '97

I had a little problem to use the new info files. I get all the time the message "node TOP not found". After removing the last line in gpc.inf (these "end tag table" was doubled) now it works fine... ___, ((__ o ,____)) V E N I

1 0

Re: Multiple inheritance (Was: OOP)
by David Fiddes 29 May '97

29 May '97

>According to Pierre Phaneuf: >> >> I strongly advises *agains't* multiple inheritance. It is the OOP 'goto' >> equivalent. Everything MI can do, you can do without MI if you design <snip snip> > * are there existing Pascal standards (ANSI Object Pascal, Delphi) > requiring it? (I *really* don't know.) <snip snip> Hi, I, also, am against MI as it, along with quite a lot of features of C/C++, make it quite a dangerous language for writing reliable programs.... Having said that I think that Interface support along the lines of Delphi 3.0/ Java IS a good idea..Unfortunately it would take quite a bit to implement I guess and (if done the Delphi way) would "tie" you to an ActiveX/OLE way of doing things as everything in Delphi 3.0 is based on the IUnknown interface with it's associated AddRef, QueryInterface and Release methods..... Just my 2p's worth, Dave ---- From: Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> To: gpc(a)hut.fi Date: 28 May 1997 11:17 Subject: Multiple inheritance (Was: OOP) >According to Pierre Phaneuf: >> >> I strongly advises *agains't* multiple inheritance. It is the OOP 'goto' >> equivalent. Everything MI can do, you can do without MI if you design >> well. C++ is the bloated monster we know today in part because of that >> pseudo-feature. Neither Modula-3 or Oberon has multiple inheritance and >> both have been used in programming operating systems and huges projects. > >I don't vote for or against multiple inheritance, but > > * are there existing Pascal standards (ANSI Object Pascal, Delphi) > requiring it? (I *really* don't know.) > > * There are few places in my planned object hierarchy (I am *also* > working on a completely new library;) where MI could be useful: > There are several independent branches of recursive objects, say > `VisibleObj' and `DataObj', which all have a `Child ( i: Integer )' > method returning the `i'th child. It would be nice to implement > some stuff, say a `ForEach' method, in a common ancestor. Without > MI, this common ancestor must be a *very* "low" object, `BaseObj' > itself, the parent of all objects. I am not sure if it is wise to > make *every* object in the hierarchy potentially recursive. > > * Whether we want to use it or not, I would like to think about how > to implement it due to academical curiousity. > > (* And: C++ has it, and we must demonstrate that GPC is not inferior. ;*) > >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] >

2 1

Re: Multiple inheritance (Was: OOP)
by The African Chief 29 May '97

29 May '97

On Wed, 28 May 1997 12:08:20 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to Pierre Phaneuf: >> >> I strongly advises *agains't* multiple inheritance. It is the OOP 'goto' >> equivalent. Everything MI can do, you can do without MI if you design >> well. C++ is the bloated monster we know today in part because of that >> pseudo-feature. Neither Modula-3 or Oberon has multiple inheritance and >> both have been used in programming operating systems and huges projects. > >I don't vote for or against multiple inheritance, If it can be done, then it should be done. However, I would advise against using it in the RTS or in any UNIT supplied as part of the GPC distribution. Let us make it's use completely optional (i.e., people can use it in their own programs if they want, but GPC is itself free from it. > but > > * are there existing Pascal standards (ANSI Object Pascal, Delphi) > requiring it? (I *really* don't know.) Delphi does not do MI. > * There are few places in my planned object hierarchy (I am *also* > working on a completely new library;) where MI could be useful: > There are several independent branches of recursive objects, say > `VisibleObj' and `DataObj', which all have a `Child ( i: Integer )' > method returning the `i'th child. It would be nice to implement > some stuff, say a `ForEach' method, in a common ancestor. Without > MI, this common ancestor must be a *very* "low" object, `BaseObj' > itself, the parent of all objects. I am not sure if it is wise to > make *every* object in the hierarchy potentially recursive. I think this is better than using MI. BP seems to have set the trend to have an almost useless ultimate ancestor for an object heirarchy. I personally do not agree with that philosophy. > (* And: C++ has it, and we must demonstrate that GPC is not inferior. ;*) Agreed :-)= 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

2 1

Multiple inheritance (Was: OOP)
by Peter Gerwinski 29 May '97

29 May '97

According to Pierre Phaneuf: > > I strongly advises *agains't* multiple inheritance. It is the OOP 'goto' > equivalent. Everything MI can do, you can do without MI if you design > well. C++ is the bloated monster we know today in part because of that > pseudo-feature. Neither Modula-3 or Oberon has multiple inheritance and > both have been used in programming operating systems and huges projects. I don't vote for or against multiple inheritance, but * are there existing Pascal standards (ANSI Object Pascal, Delphi) requiring it? (I *really* don't know.) * There are few places in my planned object hierarchy (I am *also* working on a completely new library;) where MI could be useful: There are several independent branches of recursive objects, say `VisibleObj' and `DataObj', which all have a `Child ( i: Integer )' method returning the `i'th child. It would be nice to implement some stuff, say a `ForEach' method, in a common ancestor. Without MI, this common ancestor must be a *very* "low" object, `BaseObj' itself, the parent of all objects. I am not sure if it is wise to make *every* object in the hierarchy potentially recursive. * Whether we want to use it or not, I would like to think about how to implement it due to academical curiousity. (* And: C++ has it, and we must demonstrate that GPC is not inferior. ;*) 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]

2 1

Re: A question for the C wizards... ;-) (fwd)
by Pierre Phaneuf 29 May '97

29 May '97

Here's the answer I got from one of my C wizard friend... :-) Pierre Phaneuf "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." - Edsger W. Dijkstra. ---------- Forwarded message ---------- Date: Wed, 28 May 1997 17:00:03 -0400 From: stephane.lajoie(a)belairdirect.com To: pierre(a)tycho.com Cc: grendel(a)hoth.amu.edu.pl Subject: Re: A question for the C wizards... ;-) itoa is in stdlib.h/libc.a for DJGPP. I thought it was ANSI C...? Anyway, I would suggest sprintf like this: sprintf(buf, "%i", i); Where buf is a pre-allocated buffer big enough for a decimal representation of an int and i is the value to convert. You loose the radix parameter, though. extern int _fmode is a DOS thing. If the value is O_TEXT, carriage return (0x0D) characters will be stripped on reads and added on writes as needed. Simply comment out all references to _fmode, O_TEXT and O_BINARY if __DOS__(or whatever) is not defined. The 'b' you might see in the mode string of fopen calls (ex: fopen("BobTheFile", "rb"); )is the same: simply remove it when not in DOS.

1 0

Re: OOP
by Peter Gerwinski 28 May '97

28 May '97

According to Pierre Phaneuf: > > Could this compiler generated function be generated in the program? Then > it would be optimized out if unused? Then it would have to be in the GPI file. Much effort. I think the few bytes we can save like that (Just those for the strings plus one pointer in each VMT) are not worth it, but perhaps somebody else wants to try himself on this problem? ;-) > On the other hand, maybe we should do > differently. In BP, there is a switch to have object symbols in for the > object browser. It is separate from the debugging symbol switch. Maybe we > could have a switch to have the object names and parent/childs > informations included, which the ClassName() and others functions would > consult. If the information isn't there, the ClassName() function would > return "Unknown", an empty string or something similar... This information > could be included in the VMT? This is more for you to decide... :-) I don't like that solution either. It makes units compiled with different options *really* incompatible with each other. (Programs using `ClassName' will rely on the function returning the correct result.) > Ok, can you give me an example of how to create an instance of a type > specified by TypeOf? Would probably look like this: That's almost perfect. :-) > function TStream.Get: PObject; > var > ObjID: word; > VMTLink: pointer; > LoadPtr: pointer; > P: PObject; > begin > { here some code to read the ObjID and fetch the > corresponding VMTLink. } > GetMem(P, word(VMTLink^)); WordPtr ( VMTLink )^; (* WordPtr = ^Word *) > TypeOf(P):=VMTLink; (* {$X+} is needed to compile this assignment. *) > { call the LoadPtr constructor, how do I do this correctly? } > { With @Self as the 'normal' parameter of course... } (* I suggest to define a pointer to a procedure like the constructor *) (* with an *explicit* `Self' parameter, to cast `LoadPtr' to it and *) (* then call it. *) > end; > Hmm... One thing I think isn't very clean is the way TypeOf() works "in > reverse"... It is *very* peculiar IMHO to set a value to a function! Maybe > more something like SetTypeOf(P, VMTLink)? ;-) That's why I did "hide" it behind (*$X+*). But maybe I should change this application of `TypeOf' to make `TypeOf' an implicit *field* of an object - which it is - instead of a function: PtrToMyObj^.TypeOf:= TypeOf ( SomeObjectType ); > Attached to this message is > the OBJECTS.PAS that goes with FPK-Pascal... Take a look at TObject and > TStream.Get implementations... They do assembler. Not very portable. > So a constructor does *NOTHING* more than a normal procedure? Umm... What > is the interest in a constructor then? :-) *NOTHING*. ;-) In principle, it would be possible to call just "MyObjPtr := New ( MyObjType );" without any constructor call. `New' would still initialize the implicit VMT field, and one could call a "constructor" procedure afterwards manually. I just implemented it like I did (a) for compatibility's sake and (b) because I was not so sure that this would really work and planned to change it to make constructors initilalize the object instead of `New'. But in fact this seems to work and to be more effective than BP's method. 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]

2 1

Re: bpcompat-1.0.zip
by The African Chief 28 May '97

28 May '97

On Tue, 27 May 1997 18:49:32 -0400 (EDT) Pierre Phaneuf <pp(a)dilu.ml.org> wrote: >On Mon, 26 May 1997, The African Chief wrote: > >> >Running gpc-970510 on a Red Hat Linux 4.1 system, kernel 2.0.27... >> >> Can you please tell me which (if any) of the UNITS currently compiles >> (without any change to the sources) under Linux? It is good to note >> these things in future releases. Thanks. > >Attached to this e-mail is the output of compiling each .pas files one >after the others. Thanks. The output confirms what I already noted; [1] - the DOS and CRT units are not portable to unix and Linux). This is obviously due to the use of functions from DOS.H and CTYPE.H and CONIO.H. Can anyone port those units to unix and Linux (or, put another way, are there any unix/Linux ports of dos.h, ctype.h and conio.h)? Without these, the DOS and CRT units will never port to unix/Linux. [2] the SYSTEM unit is not totally portable - because of "itoa()" which I used in the "Str" procedure. itoa() converts an int to a CString. Is there a unix/Linux equivalent of this? I can use an IFDEF to link the unix/Linux equivalent if "__UNIX__" is defined. [3] - this is the surprise - "_fmode" is said to be undefined. I thought that this variable existed on all C platforms. This is obviously not so. What is the unix/Linux equivalent (to define globally whether open() will open a file in binary or text mode)? I need to make the SYSTEM unit totally portable, so I need fixes for the "itoa()" and "_fmode" problems. Can any one shed any light? Thanks! Looks like another update to BPCOMPAT is called for! 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

2 1

Re: OOP
by The African Chief 28 May '97

28 May '97

On Tue, 27 May 1997 17:59:50 -0400 (EDT) Pierre Phaneuf <pp(a)dilu.ml.org> wrote: >On Mon, 26 May 1997, The African Chief wrote: [...] > >> At the moment, "Parent" and "Child" do nothing, and "Handle" is >> for projected future use (for handles to windowed objects - Win32, etc). > >Well, this is *exactly* what object-orientation is there for, so you add >the fields when you need them. TObject itself is a "do-nothing" object. As >such, it is *not* windowed and should *not* have any Handle field as it >won't ever have ANYTHING in it! A TWindow descendent shall add this field. Yes (but Handle is present in Delphi as well). However, the main reason for keeping it is because the OBJECTS unit exports a function which returns a pObject, which can be used to locate an object instance by its Handle (i.e., given any Handle, you would thereby be able to locate its owner). This can also be done via the object's SelfID (see below) in cases where the SelfID and Handle are different (which would invariably be the case). This is not an academic issue, because I have seen the utility of this facility in other contexts (viz - my portable "CHIEFAPP" class library, for BP 7.x, Delphi1 and Delphi2, from which project this OBJECTS unit was borrowed and cannibalised). Thus, the fields need to be in the ultimate "mother of all objects". >> "SelfID" is an integer which holds a unique numeric ID for each >> living TObject descendant. > >Does this have any projected use? It has a present use - to be able to locate every object instance by its own unique ID. See above. 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

2 1

Re: OOP
by The African Chief 28 May '97

28 May '97

On Wed, 28 May 1997 16:40:06 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: [...] >> At the moment, "Parent" and "Child" do nothing, [...] >> "SelfID" is an integer which holds a unique numeric ID for each >> living TObject descendant. > >AFAICS, they will hold the parent/child *objects*, not *classes*, and >the ID of instances. Also useful, I think, but not to be confused with >the parent/child classes, and "ObjID" (= class IDs) which should resonably >be in the VMT, since they depend only on the class, not on the instance. True. >> Can we make TObject automatically become the ancestor of each >> Object type (i.e., any object which is just defined as "Object")?; >> if so, is this desirable?; > >No. There are applications of OOP that are quite different from the class >libraries as TVL, OWL and so on. Sometimes I use objects as "convenient >records" without any need for inheritance, virtual methods or streams. I do too - fair enough ... >AFAICS, objects that are stored in streams, must be descendants of TObject. Correct. >But not all types of objects need to be able to be used in streams at all. Correct again. >I think the programmer should be allowed to decide for himself if he wants >his objects to be "streamable" (by making them descandants of TObject or >its descendants) or not. True. [...] >BTW: Would it be possible at all? Doesn't TObject refer to TStream? No, it doesn't. In bpcompat, TObject has a "Load" constructor that takes a TObject parameter. >So if TObject was a part of the "core language", also TStream would have to be. See above. >> True for a Program, false for a Unit. While the GPC compiler is *much* >> smarter than BP and would remove unused code and variables, the GNU linker >> is not able to remove dead code, it only does so if a whole Unit is unused. > >I suppose there's not much hope of getting a smarter linker in the near >future, is there? I very much hope so. >The African Chief wrote: > >> Yes (but Handle is present in Delphi as well). However, the main reason >> for keeping it is because the OBJECTS unit exports a function which returns >> a pObject, which can be used to locate an object instance by its Handle >> (i.e., given any Handle, you would thereby be able to locate its owner). > >I don't know all the details here, but isn't it possible to have a >TWindow(TObject) with Handle being a field of TWindow, and this function >returning a PWindow? This would seem natural to me. Yes, that is possible. But I don't think it does any harm to have the Handle in TObject instead. >> This is not an academic issue, because I have seen the utility of >> this facility in other contexts (viz - my portable "CHIEFAPP" class >> library, for BP 7.x, Delphi1 and Delphi2, from which project this >> OBJECTS unit was borrowed and cannibalised). Thus, the fields >> need to be in the ultimate "mother of all objects". > >Similar arguments might be applied to many kinds of fields, with the >possible danger of blowing up the "mother of all objects" very much. True. >Then it could - at best - be the mother of all objects in a particular >class library, but it wouldn't promote the goal of making it a widely >used base class. Perhaps. But there are many times when I have wished that certain things existed in BP's TObject and TWindowsObject. Making a descendant object is fair enough, but it would have been a lot easier for me if the things were in the ancestor. >> It has a present use - to be able to locate every object instance by its >> own unique ID. See above. > >I'm probably missing something - but isn't the address of an object a >"unique ID"? (One that makes it very easy to "locate" the object... ;-) That assumes that you already know the object and its address. If you already know it, there would be no point trying to locate it again. Also, there are a whole load of things that you can do with integers that you cannot do with addresses. And, suppose that, for some obscure reason, I suddenly wanted to locate all currently active object instances and/or their parents (if any), how would I do this using addresses? - but I could do this with a loop through the SelfIDs. 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 David Fiddes 28 May '97

28 May '97

From: Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> <snip> >Would an ID of 8 bytes matter, i.e. are there any stream files where >4 additional bytes per object would matter? <snip> Why not make them 16 bytes? Sounds excessive maybe but that's how big a Globally Unique IDentifier (GUID)(or more pretensiously a Universally Unique IDentifier (UUID)) is...128bits....and there's a stanard for generating them...and anyone with a windows machine has an implementation of that(and the Mac and some UNIX boxes too). Upwardly comaptible with Microsofts Component Object Model(COM) and I'm sure the likes of CORBA use them too... Dave

1 0

Re: OOP
by Frank Heckenbach 28 May '97

28 May '97

Pierre Phaneuf wrote: > I agree with you. I am in effect creating a better way to do it, but it > will NOT be in BPCOMPAT. I'm a proficient user of TV, and I'll try to have > the object parts of the BPCOMPAT package as compatible with it as > possible... It *will* be in a GPC-specific class library of mine I'll > contribute to the GPC team "When It's Ready (TM)", of course! ;-) Will the gpc class library similar to TV, so TV programs can be ported with moderate effort, or will it be essentially different? > All this is not really needed in a system similar to TV, since you can > register the objects yourself in case of conflict, resolving them to your > liking. Though it is a nice idea to have a programmer/vendor part... A > call to a unit-specific RegisterType procedure could look like this: > RegisterObjects(1), the 1 being a value selected by the application > programmer to prevent conflicts with another unit. For TV, this is probably ok. However, it might be a good idea to use the same numbering scheme for bpcompat and the gpc class library (so e.g. stream files could be used by both libraries, assuming the classes used are equivalent) - unless bpcompat was so much compatible to TV that they could use the same stream files. For a "good" system, I wouldn't like to have to call any registration procedures manually. And, as I showed, this isn't necessary if "ObjID" could be declared with the classes. > How about a dword, with > the first 16 bits for the unit ID and the last 16 bits for the object ID > itself within the unit. Gives you 64K units in a single program with 64K > objects per unit... Should be quite enough! :-) With my version, it would be 64K units "all over the world", if the IDs were fixed in the units. Of course, one could think of a way to partition 32 bit that would suffice for awhile. But, OTOH, I don't like the possibility of creating limits that could be reached in some years. Would an ID of 8 bytes matter, i.e. are there any stream files where 4 additional bytes per object would matter? > The version number isn't a good idea though... The idea with the object ID > is to spawn the correct object to load the object from the stream. The > correct way to put versioning in your streamable classes is to have a > version number stored at the beginning of your object by your Store > method, and have your Load method have a 'case' statement that loads the > object correctly according to the various versions. Probably a matter of taste. With the way you described, each class that exists in several versions has to do the work of loading the version and selecting the case by itself. I thought part of this work could be done by the stream load routines in one place. Of course, I didn't work this out completely, but generally I think each class should have to do as little work as possible (e.g. being registered, doing additional work for loading). However, if this additional work can be done in a base class and just be inherited for most "normal" classes, this would be ok to me. (Keep in mind that I'm not talking about bpcompat, but about a "good" class library that should do things the best way we can think of, regardless how Borland did things. Borland's way could only be decisive between some alternatives that are equally good otherwise.) > > This would require something like "virtual constructors", wouldn't it? > > I.e., the constructors would have to have the same parameters in all > > classes, and their addresses would be stored in the VMT. Doesn't seem > > impossible, perhaps it's the most logical thing to do. > > No... You know that New() works either this way: New(P, Init), where P is > a typed pointer (of an object type that has a Init constructor, of > course!), where P will be changed to point to the new instance or set as > nil if the object didn't construct correctly. The other way is as a > function that work like this: P:=New(PObject, Init), which will construct > a TObject and return the instance pointer (or nil). It isn't a virtual > constructor, you simply choose which object to construct. If the type is known at compile time (as is always the case in BP), the compiler knows which constructor to call. But if you want to pass a variable VMT link to "New", the runtime system needs a way to find out the address of the actual constructor. AFAICS, this can only be done by storing the constructor's address in the VMT, that's what I meant by a "virtual constructor" (and why shouldn't it be actually declared as "constructor ... virtual;"?). The stream load method should just make sure that the read VMT actually belongs to a descendant of TObject, e.g. by checking if "p^ IS TObject" after assigning "TypeOf(p^):=VMT". BTW: Is "IS" already implemented in gpc? > Yes, I agree, but let's keep in mind what we're looking to fix in this > thread is the BPCOMPAT package, which will have to look like BP libraries > are, at least on the outside. BTW, what didn't you like exactly with TV? Several things. E.g., as I said above, the "administrative work" that the programmer has to do. Since Borland wrote the compiler, they could have simplified this very much. For me, when writing "basic units", one of the main goals should always be to leave as little work to the programmer that uses the units as possible. Then, their massive use of assembler (partly for questionable efficiency matters, partly because Pascal didn't support some things that were needed - and again, they wrote the compiler, so they could have created a Pascal way to do things). And, more generally, I don't like the message-driven concept too much. I prefer things like "readkey" and so - of course, more advanced than in BP's Crt unit. And complex programs (with a look like TV) can be programmed in such a way - I know this because that's what I do in BP. The African Chief wrote: > The TObject type as I implemented it in OBJECTS.PAS has > a number of fields; > "Parent" and "Child" (each declared as a "pObject") > "Handle" and "SelfID" (each declared as an Integer) > "Name" (declared as a String[64]) > "SelfPtr" (private field declared as a "pObject") > > At the moment, "Parent" and "Child" do nothing, [...] > "SelfID" is an integer which holds a unique numeric ID for each > living TObject descendant. AFAICS, they will hold the parent/child *objects*, not *classes*, and the ID of instances. Also useful, I think, but not to be confused with the parent/child classes, and "ObjID" (= class IDs) which should resonably be in the VMT, since they depend only on the class, not on the instance. BTW: If objects constants and/or class variables are introduced, the name "VMT" will not be very appropriate then... > Can we make TObject automatically become the ancestor of each > Object type (i.e., any object which is just defined as "Object")?; > if so, is this desirable?; No. There are applications of OOP that are quite different from the class libraries as TVL, OWL and so on. Sometimes I use objects as "convenient records" without any need for inheritance, virtual methods or streams. > if so, can this solve any of the current > problems with Streams and stuff? AFAICS, objects that are stored in streams, must be descendants of TObject. But not all types of objects need to be able to be used in streams at all. I think the programmer should be allowed to decide for himself if he wants his objects to be "streamable" (by making them descandants of TObject or its descendants) or not. BTW: Making TObject the ancestor of all objects automatically would not be BP compatible... > I would have thought that some of the fields declared in TObject could > be put to better use than I have done so far - and that more fields could > be added to TObject, to cater for other things (i.e., if TObject will become > the ultimate ancestor of all Object types). No objections from me. Perhaps, in some time, most object types written will be descendants of TObject, that's ok. I just don't think this should be forced. BTW: Would it be possible at all? Doesn't TObject refer to TStream? So if TObject was a part of the "core language", also TStream would have to be. And I don't think that would be a good idea. IMHO, such things belong in basic units that can be replaced and/or modified without changes to the compiler. Peter Gerwinski wrote: > BTW, somebody knows a reasonable way how to implement multiple inheritance? I once did a comparison of several languages' concepts some years ago. One of the results were that each method leaves some problems open. :-( However, Java's way with single inheritance and "interfaces" didn't seem too bad to me (though I haven't programmed in Java). I think it could be implemented with reasonable effort, so I'd favour this way. If, however, "real" multiple inheritance is wanted for some reason (though I don't know any applications that really demand it), perhaps do it like C++ (I don't remember the details of C++ now, but it might be a good idea to not introduce yet another concept)... > True for a Program, false for a Unit. While the GPC compiler is *much* > smarter than BP and would remove unused code and variables, the GNU linker > is not able to remove dead code, it only does so if a whole Unit is unused. I suppose there's not much hope of getting a smarter linker in the near future, is there? The African Chief wrote: > Yes (but Handle is present in Delphi as well). However, the main reason > for keeping it is because the OBJECTS unit exports a function which returns > a pObject, which can be used to locate an object instance by its Handle > (i.e., given any Handle, you would thereby be able to locate its owner). I don't know all the details here, but isn't it possible to have a TWindow(TObject) with Handle being a field of TWindow, and this function returning a PWindow? This would seem natural to me. Otherwise, this might be an application for an interface (consisting of only GetHandle, perhaps). > This is not an academic issue, because I have seen the utility of > this facility in other contexts (viz - my portable "CHIEFAPP" class > library, for BP 7.x, Delphi1 and Delphi2, from which project this > OBJECTS unit was borrowed and cannibalised). Thus, the fields > need to be in the ultimate "mother of all objects". Similar arguments might be applied to many kinds of fields, with the possible danger of blowing up the "mother of all objects" very much. Then it could - at best - be the mother of all objects in a particular class library, but it wouldn't promote the goal of making it a widely used base class. > It has a present use - to be able to locate every object instance by its > own unique ID. See above. I'm probably missing something - but isn't the address of an object a "unique ID"? (One that makes it very easy to "locate" the object... ;-) Peter Gerwinski wrote: > * There are few places in my planned object hierarchy (I am *also* > working on a completely new library;) where MI could be useful: > There are several independent branches of recursive objects, say > `VisibleObj' and `DataObj', which all have a `Child ( i: Integer )' > method returning the `i'th child. It would be nice to implement > some stuff, say a `ForEach' method, in a common ancestor. Without > MI, this common ancestor must be a *very* "low" object, `BaseObj' > itself, the parent of all objects. I am not sure if it is wise to > make *every* object in the hierarchy potentially recursive. Also looks like an application for interfaces... > (* And: C++ has it, and we must demonstrate that GPC is not inferior. ;*) Blindly copying useless features doesn't exactly prove superiority... (I'm not claiming MI is useless for now, but I've yet to see an example that really justifies the problems.) -- 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: bpcompat-1.0.zip
by Peter Gerwinski 28 May '97

28 May '97

According to The African Chief: > > [2] the SYSTEM unit is not totally portable - because of "itoa()" which > I used in the "Str" procedure. itoa() converts an int to a CString. Is there > a unix/Linux equivalent of this? I can use an IFDEF to link the unix/Linux > equivalent if "__UNIX__" is defined. You can convert an Integer to a String using Extended Pascal's `WriteStr' procedure: WriteStr ( MyString, i : 7 ); This *is* portable. 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: bpcompat-1.0.zip
by The African Chief 27 May '97

27 May '97

On Sun, 25 May 1997 01:37:37 -0400 (EDT) Pierre Phaneuf <pp(a)55-174.hy.cgocable.ca> wrote: >On Fri, 23 May 1997, The African Chief wrote: > >> a. If anyone is working on anything, please let me know *exactly* >> what you are doing or proposing to do, so that there will be no >> duplication of efforts; > >Ok, so I'll be modifying the Put and Get methods of TStream, and adding a >class registry. (probably will be very simple) Ok - thanks. I will note that. >> >I send you the update! Shouldn't take more than a few days (download and >> >install the newest GPC and do the changes)... >> >> That would be excellent! What platform are you using (DJGPP, EMX, etc ...)? > >Running gpc-970510 on a Red Hat Linux 4.1 system, kernel 2.0.27... Can you please tell me which (if any) of the UNITS currently compiles (without any change to the sources) under Linux? It is good to note these things in future releases. Thanks. 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

2 1

Re: OOP
by The African Chief 27 May '97

27 May '97

Hi all, I have been following the discussion on Objects with interest. I would just like to note a number of things; The TObject type as I implemented it in OBJECTS.PAS has a number of fields; "Parent" and "Child" (each declared as a "pObject") "Handle" and "SelfID" (each declared as an Integer) "Name" (declared as a String[64]) "SelfPtr" (private field declared as a "pObject") At the moment, "Parent" and "Child" do nothing, and "Handle" is for projected future use (for handles to windowed objects - Win32, etc). "SelfID" is an integer which holds a unique numeric ID for each living TObject descendant. Can we make TObject automatically become the ancestor of each Object type (i.e., any object which is just defined as "Object")?; if so, is this desirable?; if so, can this solve any of the current problems with Streams and stuff? I would have thought that some of the fields declared in TObject could be put to better use than I have done so far - and that more fields could be added to TObject, to cater for other things (i.e., if TObject will become the ultimate ancestor of all Object types). Any views? 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

2 1

Re: OOP
by Peter Gerwinski 27 May '97

27 May '97

According to Pierre Phaneuf: > > If the VMT offset given is the same as the called constructor, then it is > the first constructor called and the object is initialized. If the VMT > parameter isn't the same as the called constructor, it is because it is > being called from within another constructor and hence the object is > already initialized. This is actually easy! ;-) Sorry, but I don't understand this (perhaps it's too easy for me;). How can the VMT offset be the same as a constructor? AFAIK, BP passes a VMT offset of zero to constructors which shall *not* initialize an object. > [...] > This doesn't give much information about the object apart from its size > and the number of methods and where they are... What we'd need is > something like from which class is another class derived from, its name, > and so on... So we should extend the VMT. Okay, why not ... BTW, somebody knows a reasonable way how to implement multiple inheritance? > Hmm... Is it possible to have a function automatically generated by the > compiler before going to the optimizing stage? It would contain a table > translating VMT pointers into strings of the classes name No problem. > and would be > optimized out of the program by the optimizer if unused, right? True for a Program, false for a Unit. While the GPC compiler is *much* smarter than BP and would remove unused code and variables, the GNU linker is not able to remove dead code, it only does so if a whole Unit is unused. > [...] > What I mean is (for example) a NewObject() function that would work just > like New(), but instead of a typed pointer or an object type itself, it > would take a VMT pointer as the first parameter. It would make the > construction of an object from a stream as simple as calling > "Get:=NewObject(TStreamRec.VMTLink, Load(@Self));" at the end of the > TStream.Get method. It should not be difficult to implement this using `GetMem' and an explicit assignment to `TypeOf'. > BTW, how does New() work when it is passed an object type (say, PObject) > as the first parameter? The compiler picks up the (constant) size of the object, calls `GetMem', initializes the VMT field and finally calls the constructor. (In BP, the value for the VMT field is passed to the constructor which does the assignment, but I see no reason for that.) 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]

2 1

new cygwin32 binaries.
by Jan-Jaap van der Heijden 27 May '97

27 May '97

Hello all, I have built GPC binaries for cygwin32 beta18. I used alpha-970526 with some custom modifications. Get it from ftp://agnes.dida.physik.uni-essen.de/home/janjaap/cygwin32/ gpc-i970526.i386-cygwin32-b18.zip Also in this directory is cdkgpc-970518.pentiumpro-intel-cygwin32-b18.zip Unlike most other GPC's this one isn't built using gcc-2.7.2.1, but I used the 970404 cygnus snapshot. The resulting binary can generate pentium(pro) optimized code. Also, it uses a separate gpc.exe pre-driver, (like g++ and g77 do), a method I have decided not to continue because it gives great problems with the automake feature (which is broken in this binary). You could also use this gpc1.exe as a drop-in replacement for the more conservative gpc1.exe from gpc-i970526 :-) Have fun, JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

Re: OOP
by The African Chief 27 May '97

27 May '97

On Mon, 26 May 1997 20:09:51 -0400 (EDT) Pierre Phaneuf <pp(a)dilu.ml.org> wrote: >On Mon, 26 May 1997, Frank Heckenbach wrote: > >> Bottom line: I don't think it can be done all automatically, but it can be >> done much more comfortably to the programmer than in TV. > >I agree with you. I am in effect creating a better way to do it, but it >will NOT be in BPCOMPAT. I'm a proficient user of TV, and I'll try to have >the object parts of the BPCOMPAT package as compatible with it as >possible... It *will* be in a GPC-specific class library of mine I'll >contribute to the GPC team "When It's Ready (TM)", of course! ;-) It would be nice if your classlib could build on the object heirarchy in BPCOMPAT, instead of introducing a completely new one (at least, if all your main "PierreObject" is a descendant of TObject). This would ensure some continuity. You could amend TObject if necessary, so that it would meet your needs as the ultimate ancestor of your own objects. All that is necessary is to ensure that programs written to use TObject as it currently is (which would be very few indeed) are not broken, which will be a trivial thing to do. Also, when implementing your new TV stuff, it would be nice to make it more friendly. I find Borland's TV quite incomprehensible - it is as if it wasn't made by the same company that made OWL (which I find to be easier to deal with). But perhaps it is because I lost patience with TV very quickly. [...] >> > We are in part. The primary goal of GPC is to produce the best Pascal >> > compiler the world has ever seen. >> >> I agree with Peter. I, FWIW, didn't use TV -- partly because some parts >> of it (including class registration) were, IMHO, badly implemented. >> If gpc's TV would be the same, I probably wouldn't use it, either. > >Yes, I agree, but let's keep in mind what we're looking to fix in this >thread is the BPCOMPAT package, which will have to look like BP libraries >are, at least on the outside. I think that this is crux of the matter. We are trying to produce a package that will allow GPC to compile BP programs (i.e., the external interface is similar to that of BP). We are not concerned to ensure that the internal implementation is identical to that of BP (unwanted side effects aside). We are also not concerned to ensure that the code will compile under BP itself. Much of the current BPCOMPAT will not compile under BP, because of the use of functions from the C library, and the use of EP initialization and finalization stuff. So, please let us not hamstring ourselves by trying only to write code that will also compile under BP. Eventually, BP will go the way of the dodo - GPC is the way forward! > BTW, what didn't you like exactly with TV? Personally, it seemed too tedious to write any useful code. Felt like it was a classlib written by a sadist or a masochist, or both ;-). However, some people feel that way about OWL too - and I personally prefer OWL to TV or even to Delphi's VCL. >As for the class registration, what I didn't like was that it used the >data segment, which isn't a very clean hack IMHO... Apart from that, it's >ok by me (the class registration system!). The Free method is one of the >purest evils in there. :-) (and it is in the BPCOMPAT package!) Well, Free() was included just because Borland included it (i.e., "external" compatibility). >> So we may need both: a "100% BP compatible" unit for quick changes, and >> a "better" gpc unit to which programs can be converted afterwards, and >> which new programs can use from the beginning. Actually, I think, the >> changes needed for BP programs shouldn't be too big: make the "Load" >> constructor virtual (if we do it this way), declare the "ObjID" constant, >> and remove the registration stuff. Could even be simplified with some >> "IFDEF"s and clever use of the preprocessor, I guess. > >I'm developing something here for a "GPC enhanced" class library, I'll >keep you posted! That would be great. Which objects are you thinking of including? Are you tailoring it after [a] TV (eek!!); [b] OWL (:-)); [b] VCL ( !!); [d] OPRO (;-/); [e] something else ? >"The use of COBOL cripples the mind; its teaching should, therefore, be >regarded as a criminal offense." - Edsger W. Dijkstra. Except it can save the world from the Year 2000 fiasco! 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

2 1

Re: OOP
by Frank Heckenbach 27 May '97

27 May '97

Peter Gerwinski wrote: > > Couldn't "Load" be a virtual method instead of a constructor (perhaps a > > Boolean function that returns if it didn't fail)? > > Yes. IMHO, it could be in BP as well. I never used TV, but I'd think so, too. > > And it would be even better if the compiler could do this automatically, > > i.e. each object type could (optionally) declare an "ObjType" value, and > > the compiler would provide functions to get the ObjType from a VMT link > > and vice versa. > > Sounds nice, but how to find a unique number for each object? Derive it > from the name? I don't think it's possible (or sensible) that the compiler derives it automatically. I thought about this problem several times, but didn't find a "good" solution. The name? It can change (if you change your naming conventions, or just don't like the name you chose), and it's against the "rule" that the identifiers should not influence the compiled code (I'm not sure if this is actually a rule in the Pascal syntax, but anyway I personally like it this way). Also, there are other questions involved. If the code of the object type changes, should it get a new ID or not? I think, only the programmer can decide this. If all the object's fields and their semantics stay the same, the ObjID can usually stay the same. Also, of course, if the object is in the developing/debugging process. But if the "interface" of an object in a published program changes, the ID should change as well, to avoid compatibility problems with older stream files. Bottom line: I don't think it can be done all automatically, but it can be done much more comfortably to the programmer than in TV. What I meant was that the programmer declares the ID, like type MyObject(TObject) Const ObjID:Word = MyBaseID+42; ... End; or ... why not also Const ObjID:Word = Inherited ObjID+1; (Though the simple "+1" might not be good, as it can easily lead to conflicts - but perhaps something similar.) Concerning the numbering convention, I'd also suggest something "better" than TV's way, perhaps an ID consisting of 4 parts (perhaps 16 bits for each part, this would leave room for a growing number of programs for some time (well - at least as long as 640 KB are enough for everybody... ;-), and the whole thing would be 64 bits (longlongint?)): 1. "unique" programmer ID 2. ID for a "category" of types (graphical objects, mathematical objects, dialog elements, ...) - unique only for the programmer 3. ID for a certain type within a category 4. "version number" for the type (i.e., if the fields or their semantics change, the version number will be changed, too, so that old objects in streams can be recognized) > Then what about storing the name of the object itself > in the Stream? As I said above, I wouldn't like this. But it could be an idea to have ObjID be a string instead of a numerical value. But I'm not sure if it's worth the additional work required... > > Thinking about how to implement this, I realize this is basically the same > > as object constants -- something that's missing in BP and I could've used > > sometimes. This could be a useful extension to BP's objects. (The constants > > and their values would be inherited if not redeclared, just like virtual > > methods.) > > And they would be stored in the VMT. Sounds reasonable. Exactly. They would need to be _typed_ constants then, wouldn't they? (But there's no problem about it, except that the programmer has to type a little bit more...) Just an addition to the class variables (this might complicate matters a bit more, though): The question is, should the variables be shared with child types or duplicated? I think there could be applications for both. To make clear what I mean, an example: Type "a" declares a class variable "v". Type "b(a)" doesn't redeclare "v", so it uses the same variable as "a". Type "c(a)" redeclares "v", so it gets a variable of its own (of course, it must be of the same type as "a.v", but it could have a different initializer). Does this seem reasonable? To implement this, there must be a pointer to the actual variable in the VMT (which would point to the same variable for "a" and "b", and to a different variable for "c"). > Sounds good, but I think the "stabilization" of gpc-2.1 has higher > priority. But this might be of interest for gpc-2.2 ... I (at least) am not in a hurry (now)... ;-) Pierre Phaneuf wrote: > And also not put all the symbols in every programs, just those that use > the "ClassName()" function, optimizing those using constants as their > parameter and so on... Perhaps it's easier to let "ClassName" be a normal object constant (if they'll be implemented). Then the programmer could decide which names to include in the program and how to call them (e.g. the actual identifier might be "TSomething", but for the ClassName it might be preferable to have just "Something"). > The way I see it, the best way is to make a legal way to directly call a > specific class constructor. Like the "typed new()" function (passing an > object type as the first parameter) does, but being able to put a variable > there. Maybe a GPC-specific new() function? With another name of course to > avoid incompatibilities... This would require something like "virtual constructors", wouldn't it? I.e., the constructors would have to have the same parameters in all classes, and their addresses would be stored in the VMT. Doesn't seem impossible, perhaps it's the most logical thing to do. Peter Gerwinski wrote: > Look whether the VMT field contains a nonzero value. To be absolutely > sure, we can even check whether the pointer really points to a VMT: The > first Word pointed to must be a positive Integer (the size of the object), > the second one its negative (which is included for purposes like this > one). Problem: This will only work if the object was pre-initialized > to have a zero VMT field. This can be achieved with `New', but not with > `GetMem', so you have still to be careful when implementing streams. And what about non-dynamic objects (i.e. in the global data or the local data of a procedure)? They're not often used as it seems, but AFAIK it's legal to do so -- and I do sometimes. In order to rely on this method, the compiler would have to initialize their VMT fields to 0, even if the variable is "uninitialized". Then we could be sure in all cases but GetMem, and since GetMem is a "dirty trick", it's the programmer's responsibility to set the VMT to 0 (or whatever) after GetMem'ming. > > Are we looking for BP compatibility or not? > > We are in part. The primary goal of GPC is to produce the best Pascal > compiler the world has ever seen. I agree with Peter. I, FWIW, didn't use TV -- partly because some parts of it (including class registration) were, IMHO, badly implemented. If gpc's TV would be the same, I probably wouldn't use it, either. > (See the Info documentation for > details.) BP compatibility is desireable because (ii) BP is not too > bad and (i) many BP programmers will try GPC only if they can use their > existing programs without any change. So we may need both: a "100% BP compatible" unit for quick changes, and a "better" gpc unit to which programs can be converted afterwards, and which new programs can use from the beginning. Actually, I think, the changes needed for BP programs shouldn't be too big: make the "Load" constructor virtual (if we do it this way), declare the "ObjID" constant, and remove the registration stuff. Could even be simplified with some "IFDEF"s and clever use of the preprocessor, I guess. > How does Delphi do this? (Sorry for the stupid question, but my > experience with Delphi is very limited, primarily because I cannot stand > the mouse-only "user interface".) Argh! Mouse-only for a programmers' tool??? Lucky me that I didn't buy it! > What about making the structure of the VMT record visible for the program? > For instance a built-in > > Type > VmtRec = record > Size, NegSize: Integer; > VirtualMethod: array [ 0..1 ] of Pointer; > end (* VmtRec *); > > Where the `1' above stands for the unknown number of methods in a VMT. Then it should be "0..0" or "1..1", but I prefer the following. > (* I thought about changing the VMT to a schema type > > Type > VmtRec ( n: Integer ) = record > Size, NegSize: Integer; > VirtualMethod: array [ 1..n ] of Pointer; > end (* VmtRec *); > > which would place `n' as an additional field at the very beginning of > each VMT. But it's probably better to let `Size' stay the first field and > to save the additional storage for the number of methods in the object. *) I think it's worth the 4 bytes to have a cleaner structure and not introduce new "dirty tricks" -- just my experience from the way Borland messed up their objects. It also wouldn't be the best promotion for schema types, if this build-in structure, where schema types seem natural, didn't use them. OTOH, the introduction of object constants would break this structure anyway, since the VMT wouldn't contain only pointers then. So perhaps only declare Type VmtRec = record Size, NegSize: Integer; MethodsAndConstants: Void; end (* VmtRec *); and leave all access to "MethodsAndConstants" to the programmer's responsibility (though I don't see any need for this at all -- I think anything can be achieved by assigning the VMT offset to an object, and accessing its fields/methods by normal means). (BTW: Is "Void" a valid declaration of size 0? Otherwise perhaps "record end", this is allowed at least in BP.) A "Parent" field in the VMT seems quite useful to me. Also, a list of the childs (this would require a "FirstChild", and a "Sibling" field in each VMT). And perhaps they could be accessed through the VmtRec as well as as normal object constants... -- 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

2 1

Re: OOP (Was: bpcompat-1.0.zip)
by Peter Gerwinski 26 May '97

26 May '97

According to Pierre Phaneuf: > > That's the problem (that you're not sure it will not change). BTW, the > constructor *is* the logical place do to such a thing... I agree, but not every constructor call does actually initialize an object. Since it is difficult to be sure whether an object already is initialized or not, we have to decide about this when the constructor is *called*. For this reason, it happened to be easier to do the initialization outside the constructor's body. If we find a method to be *sure* if the object is initialized, I can change constructors to do initialization in the body. Anyway, this does not matter unless you do tricks like `GetMem'ming an object. > But how do you check if an object is initialized or not? Look whether the VMT field contains a nonzero value. To be absolutely sure, we can even check whether the pointer really points to a VMT: The first Word pointed to must be a positive Integer (the size of the object), the second one its negative (which is included for purposes like this one). Problem: This will only work if the object was pre-initialized to have a zero VMT field. This can be achieved with `New', but not with `GetMem', so you have still to be careful when implementing streams. > I don't think > this is the best way either, unless you can devise a *sure* way to check > out if the object is initialized. What else would you propose? > In BP it cannot. It *must* be a constructor, because this is relied upon > by TStream.Get to initialize the object VMT link correctly and allocate > the correct amount of memory. It could be in BP too, if we changed the `tStream' object. Just do everything, the constructor would normally do, by hand. > I am doing a BP compatible StreamRec facility for the BPCOMPAT package. Great! }:-=)= (* This shall be a smiling Gnu. :*) > Are we looking for BP compatibility or not? We are in part. The primary goal of GPC is to produce the best Pascal compiler the world has ever seen. (See the Info documentation for details.) BP compatibility is desireable because (ii) BP is not too bad and (i) many BP programmers will try GPC only if they can use their existing programs without any change. > BTW, I *am* also developing a > class library made just for GPC using all the new features and fixing many > of the problems with the BP OBJECTS.PAS and the TurboVision libraries. :-) > It would be nice to have RTL functions to get an object name and parent, > a bit like Delphi can give you the class name of an object. How does Delphi do this? (Sorry for the stupid question, but my experience with Delphi is very limited, primarily because I cannot stand the mouse-only "user interface".) > A separate > function would be better (probably something accepting a VMT pointer (as > returned by TypeOf() ) as a parameter), since it wouldn't "use up" a > method name. What about making the structure of the VMT record visible for the program? For instance a built-in Type VmtRec = record Size, NegSize: Integer; VirtualMethod: array [ 0..1 ] of Pointer; end (* VmtRec *); Where the `1' above stands for the unknown number of methods in a VMT. (* I thought about changing the VMT to a schema type Type VmtRec ( n: Integer ) = record Size, NegSize: Integer; VirtualMethod: array [ 1..n ] of Pointer; end (* VmtRec *); which would place `n' as an additional field at the very beginning of each VMT. But it's probably better to let `Size' stay the first field and to save the additional storage for the number of methods in the object. *) > And also not put all the symbols in every programs, just those that use > the "ClassName()" function, Difficult. > optimizing those using constants as their parameter Easier. > and so on... Most difficult. > A unique number is a bad idea and shouldn't be used. They can change and > invalidate a file containing streamed objects from compile to compile. That's what I meant with the "how to choose" problem. When deriving it from the name in an unambiguous way, it would work. But how would that "unambiguous way" look like? A CRTC check sum? (I don't really know what that is ...;) > The way I see it, the best way is to make a legal way to directly call a > specific class constructor. Like the "typed new()" function (passing an > object type as the first parameter) does, but being able to put a variable > there. Maybe a GPC-specific new() function? `New' already is as GPC-specific as it could be ... > With another name of course to > avoid incompatibilities... I will think about that and let you know if I have an idea. 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]

2 1

Re: OOP (Was: bpcompat-1.0.zip)
by Peter Gerwinski 26 May '97

26 May '97

According to Frank Heckenbach: > > Though the VMT format might not be likely to change, perhaps it would be > better to have a built-in function of the compiler to return the object > size of a given VMT link (should be easy to implement). It's easy to implement as a function: Let `pObject' be a pointer to the parent object `tObject'of all `Stream'able objects, then (*$X+*) (* For hackers, only *) Function ObjectSizeInBytes ( VmtLink: Pointer ): Word; Var O: tObject; begin TypeOf ( O ):= VmtLink; (* Initialize it manually *) ObjectSizeInBytes:= SizeOf ( O ); end. According to Pierre Phaneuf: > > This wouldn't work (in BP at least), since this will call TObject's Load > constructor and it will reset the type of the object to TObject, whatever > has been set with TypeOf(). In GNU Pascal, initialization takes place outside the constructor as some additional inline code. (I am not 100% sure that this will not change.) But you are right - this does not work in the current GPC either. But I can modify GPC such that constructors only initialize an object if it has not been initialized previously. Then it will work, since assignment to `TypeOf ( something )' *is* (manual) initialization. According to Frank Heckenbach: > > Couldn't "Load" be a virtual method instead of a constructor (perhaps a > Boolean function that returns if it didn't fail)? Yes. IMHO, it could be in BP as well. > But if it's possible, you also wouldn't have to register the Load constructor > (neither Store, of course), so the registration could also be simplified to > something like > RegisterType(ObjType, VMTLink:Word); > and the programs that use this function don't have to declare a "StreamRec" > manually, which would be another simplification. Exactly. For compatibility's sake, somebody should implement the "StreamRec" stuff, too, but it can be done in an easier way. > And it would be even better if the compiler could do this automatically, > i.e. each object type could (optionally) declare an "ObjType" value, and > the compiler would provide functions to get the ObjType from a VMT link > and vice versa. Sounds nice, but how to find a unique number for each object? Derive it from the name? Then what about storing the name of the object itself in the Stream? > Thinking about how to implement this, I realize this is basically the same > as object constants -- something that's missing in BP and I could've used > sometimes. This could be a useful extension to BP's objects. (The constants > and their values would be inherited if not redeclared, just like virtual > methods.) And they would be stored in the VMT. Sounds reasonable. And the compiler could (optionally?) provide an automatic "name" object constant and/or a unique number ... > [...] > > Just some ideas... Sounds good, but I think the "stabilization" of gpc-2.1 has higher priority. But this might be of interest for gpc-2.2 ... 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]

2 1

Re: bpcompat-1.0.zip
by The African Chief 25 May '97

25 May '97

On Fri, 23 May 1997 10:57:29 -0400 (EDT) Pierre Phaneuf <pp(a)55-174.hy.cgocable.ca> wrote: >> They worked okay in my tests. See the procedure "TestPut" in >> TESTSTRM.PAS. Can you post a copy of the code that is broken? > >The problem is that TStream.Put simply write off the image of the object >without any type information. [...] Yes, that is correct. >> BTW: it is stated clearly that TStream and some of the other >> objects are not complete - so, if anyone wants to implement >> the missing bits, please feel free to do so! > >Of course! Peter says the features needed to implement the TStream object >correctly is now in GPC, so I'll get the latest version and work on this! That would be great. Here is an excerpt from my announcement, concerning improvements on the package; [------------------ cut -------------------] Please, let this work be done in a coordinated fashion; a. If anyone is working on anything, please let me know *exactly* what you are doing or proposing to do, so that there will be no duplication of efforts; b. Please follow the conventions in the existing code, for comments, spacing, and so on; c. Please mark clearly any changes that you have made to my code, or to Peter's code; d. If you are working on the SYSTEM unit, please ensure that what you are doing it portable (e.g., by using only C functions that are portable across DOS, OS/2, Unix, etc.); e. When uploading your work, please upload everything in one package (.zip file), and put a version number on it. f. Please inform Peter and me when you are ready to upload a new version. [------------------ end cut -------------------] >> It isn't there - but you could write it :-). We would greatly welcome >> all contributions to the bpcompat package! > >I send you the update! Shouldn't take more than a few days (download and >install the newest GPC and do the changes)... That would be excellent! What platform are you using (DJGPP, EMX, etc ...)? 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

2 1

OOP (Was: bpcompat-1.0.zip)
by Frank Heckenbach 25 May '97

25 May '97

Pierre Phaneuf wrote: > Ah, I didn't knew the size was at the beginning of the VMT... But this > isn't quite the Right Way (if the VMT format changes for whatever reason), > no? Though the VMT format might not be likely to change, perhaps it would be better to have a built-in function of the compiler to return the object size of a given VMT link (should be easy to implement). > > 4) Call the object's `Load' constructor. > > This could cause problems. How shall I call the Load constructor? > > function CreateObject(VMTLink: pointer; S: PStream): PObject; > var > P: PObject; > Size: ^word; > begin > Size:=VMTLink; > getmem(P, Size^); > TypeOf(P):=VMTLink; > P^.Load(S); > end; > > This wouldn't work (in BP at least), since this will call TObject's Load > constructor and it will reset the type of the object to TObject, whatever > has been set with TypeOf(). Couldn't "Load" be a virtual method instead of a constructor (perhaps a Boolean function that returns if it didn't fail)? I'm not sure if a constructor does anything special besides setting the VMT link which has been done here anyway, so if it does more, this suggestion might not be possible. But if it's possible, you also wouldn't have to register the Load constructor (neither Store, of course), so the registration could also be simplified to something like RegisterType(ObjType, VMTLink:Word); and the programs that use this function don't have to declare a "StreamRec" manually, which would be another simplification. And it would be even better if the compiler could do this automatically, i.e. each object type could (optionally) declare an "ObjType" value, and the compiler would provide functions to get the ObjType from a VMT link and vice versa. Thinking about how to implement this, I realize this is basically the same as object constants -- something that's missing in BP and I could've used sometimes. This could be a useful extension to BP's objects. (The constants and their values would be inherited if not redeclared, just like virtual methods.) "ObjType" could then be a normal object constant with only 2 differences: the compiler should make sure that no two types within a program have the same ObjType (especially, that no type accidentally inherits its parent's value!), and there must be a special function to get the VMT link from an ObjType. And while I'm at it, class variables would also be nice, i.e. variables that exist only once for all instances of an object type (aka class). Again, I had some situations where I liked to have them. (For variables, there is a difference between object and class variables, for constants this difference doesn't matter.) Just some ideas... -- 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: bpcompat-1.0.zip
by Peter Gerwinski 23 May '97

23 May '97

According to Pierre Phaneuf: > > I just checked out the new bpcompat sources... Did anyone actually *USED* > the OBJECTS.PAS unit??? More specifically, the TStream Put and Get > methods? They are obviously broken... This is a very first release, and the `tStream' object is marked as "{ !!! not complete !!! }". Now you know what was meant with the statement "and some of the routines do not work well" in the announcement. > Ok, so those are difficult parts, but still... What I need is two things: > a way to tell what is the real type of an object like the typeof() > function (didn't check if it was there), It is there since gpc-970510 (see the announcement). > and a way to construct an object > of an type as returned by typeof(). >From the announcement of gpc-970510: * `TypeOf' applied to object variables works now, too. As a GPC extension, you can explicitly assign a value to "TypeOf ( MyObj )" if extended syntax is ON (*$X+*). This means that, with (*$X+*), you can explicitly assign a `TypeOf' to an object. I implemented this extension just for the purpose to write the `tStream.Get' method. (In BP, this is achieved with assembler, but we want to have it portable for GPC.) > Something that would enable me to do something so that > new(typeof(TMyObject), Init) creates an instance of TMyObject, calls Init > and returns a pointer to the newly created object would be just *perfect*. Please add it to `objects.pas'! My suggestion: 1) Write a `RegisterType' function, so you can read the `ObjType' out of the stream and look up its `VmtLink'. 2) Replace the `New' in `tStream.Get' by a `GetMem' with the Size read off the VMT (a Word variable at the very beginning of the VMT). 3) Explicitly assign `VmtLink' to `TypeOf ( the new object )'. 4) Call the object's `Load' constructor. Please join us in improving GPC! 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]

2 1

Re: bpcompat-1.0.zip
by The African Chief 23 May '97

23 May '97

On Thu, 22 May 1997 20:12:09 -0400 (EDT) Pierre Phaneuf <pp(a)gulliver.qc.ca> wrote: >I just checked out the new bpcompat sources... Did anyone actually *USED* >the OBJECTS.PAS unit??? Yes - see; TESTOBJ.PAS TESTCOLL.PAS TESTSTRM.PAS >More specifically, the TStream Put and Get methods? Yes - see; TESTSTRM.PAS > They are obviously broken... They worked okay in my tests. See the procedure "TestPut" in TESTSTRM.PAS. Can you post a copy of the code that is broken? BTW: it is stated clearly that TStream and some of the other objects are not complete - so, if anyone wants to implement the missing bits, please feel free to do so! >Ok, so those are difficult parts, but still... What I need is two things: >a way to tell what is the real type of an object like the typeof() >function (didn't check if it was there), and a way to construct an object >of an type as returned by typeof(). It isn't there - but you could write it :-). We would greatly welcome all contributions to the bpcompat package! 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

2 1

bpcompat-1.0.zip
by Pierre Phaneuf 23 May '97

23 May '97

I just checked out the new bpcompat sources... Did anyone actually *USED* the OBJECTS.PAS unit??? More specifically, the TStream Put and Get methods? They are obviously broken... Ok, so those are difficult parts, but still... What I need is two things: a way to tell what is the real type of an object like the typeof() function (didn't check if it was there), and a way to construct an object of an type as returned by typeof(). Something that would enable me to do something so that new(typeof(TMyObject), Init) creates an instance of TMyObject, calls Init and returns a pointer to the newly created object would be just *perfect*. Pierre Phaneuf

1 0

Re: GPC Question (or bug)
by Peter Gerwinski 22 May '97

22 May '97

According to Phil Robertson: > > I've ran into a problem compiling separate UNITS using > "borland-pascal" style syntax. Essentially individual > elements in an ENUM declared in an INTERFACE are not > "recognized" by gpc-2.0: I could reproduce this bug - and fix it. The next alpha release of GPC - perhaps this weekend ... or maybe we should start to call it a "beta" release ... - will compile your programs correctly. > I assume no "type cast" error is reported since full > pascal type/range checking is not as yet implemented. Indeed. I fixed this, too. Thanks for reporting these bugs, 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

GPC Question (or bug)
by Phil Robertson 22 May '97

22 May '97

I've ran into a problem compiling separate UNITS using "borland-pascal" style syntax. Essentially individual elements in an ENUM declared in an INTERFACE are not "recognized" by gpc-2.0: testunit1.pas: UNIT TestUnit1; INTERFACE TYPE Wood = (Oak, Pine, Beech, Teak); Fruit = (Apples, Peaches, Lemons); CONST Oranges = Teak; PROCEDURE CheckFruit ( FruitType : Fruit ); IMPLEMENTATION PROCEDURE CheckFruit ( FruitType : Fruit ); BEGIN CASE FruitType OF Apples : Writeln ('Apples'); Peaches : Writeln ('Peaches'); Lemons : Writeln ('Lemons'); END; END; END. <gpc -c testunit1.pas> compiles with no errors. testunit2.pas: UNIT TestUnit2; INTERFACE USES TestUnit1; PROCEDURE UseFruit; IMPLEMENTATION PROCEDURE UseFruit; BEGIN CheckFruit (Apples); CheckFruit (Peaches); CheckFruit (Lemons); CheckFruit (Oranges); END; END. <gpc -c testunit2.pas> yields: testunit2.pas: In function `Usefruit': testunit2.pas:13: undeclared identifier `Apples' (first use this function) testunit2.pas:13: (Each undeclared identifier is reported only once testunit2.pas:13: for each function it appears in.) testunit2.pas:14: undeclared identifier `Peaches' (first use this function) testunit2.pas:15: undeclared identifier `Lemons' (first use this function) It's interesting that "Oranges" is recognized since it is a const. I assume no "type cast" error is reported since full pascal type/range checking is not as yet implemented. Does anyone know of a fix or work-around for this? We're trying to port some code still in production and are stuck with a 10 year old compiler from Silicon Valley Software (now defunct). Thanks; Phil ------------------------------------------------------------------------- Philip A. Robertson <phil_robertson(a)gilbarco.com> Gilbarco Inc. F-78 Phone (910) 547-5164 7300 W. Friendly Ave Fax (910) 292-8871 Greensboro, NC 27410 -------------------------------------------------------------------------

1 0

GPC ok (fwd)
by Vadim Aleksandrovich Denisyuk 21 May '97

21 May '97

GPC works. Thanks Go...Peter ---------- Forwarded message ---------- Date: Wed, 21 May 1997 15:41:16 +0200 (MET DST) From: Super-User <root(a)fis.unico.it> To: Vadim Denisyuk <denisyuk(a)fis.unico.it> Subject: GPC ok Ok, I finally succeeded in correctly compiling the new GPC. Amazingly, it works, thanks to the last suggestion.

1 0

GPC and G77 (was without subject)-;
by Peter Gerwinski 20 May '97

20 May '97

DENISYUK VEDIM A wrote: > ---------- Forwarded message ---------- > Date: Mon, 19 May 1997 15:13:18 +0200 (MET DST) > From: fB <frances(a)fis.unico.it> > To: Vadim Denisyuk <denisyuk(a)fis.unico.it> > Subject: GPC compiled, but it does not work. > [...] > ========================================================================= > % ./gpc -c test/standard_pascal/hello.pas > gpc: test/standard_pascal/hello.pas: linker input file unused since > linking not done > ========================================================================= > So I probably messed up the command parser somewhere (see note). You are using the wrong `gpc' driver program: It does not recognize Pascal source files and thinks they are for the linker. To fix this, make sure that the correct `gcc.o' is linked to produce the `gpc' driver program. It's the same problem as with `stor-layout.o' etc., and the solution is the same, too (see my previous mail). Good luck, 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

None
by DENISYUK VEDIM A 19 May '97

19 May '97

Hi guys, Did somebody have experience to install g77 and gpc together (the newest versions?)? If it is you can you read the set of messages below with me and my system administrator to help us. Yous, Vadim ---------- Forwarded message ---------- Date: Mon, 19 May 1997 10:47:30 +0200 (MET DST) From: fB <frances(a)fis.unico.it> To: Vadim Aleksandrovich Denisyuk <denisyuk(a)fis.unico.it> Subject: Re: Linking errors (fwd) Peter wrote: > 1. Get a recent version of GNU make. Version 3.74 or better is known > to work. > 2. Build GCC in a seperate directory instead of using the GCC source > directory. > 3. Manually delete these files from the GCC object directory: > `stor-layout.o' `dbxout.o' `expr.o' `fold-const.o' `optabs.o' > `convert.o' `function.o' `setop.o' `toplev.o' then resume `make'. This was in the FAQ. Still I have: Undefined first referenced symbol in file reg_known_equiv_p ../gcc-2.7.2.2/sched.o read_dependence ../gcc-2.7.2.2/sched.o record_base_value ../gcc-2.7.2.2/loop.o output_dependence ../gcc-2.7.2.2/sched.o true_dependence ../gcc-2.7.2.2/cse.o anti_dependence ../gcc-2.7.2.2/sched.o flag_alias_check ../gcc-2.7.2.2/calls.o reg_known_value ../gcc-2.7.2.2/sched.o init_alias_analysis ../gcc-2.7.2.2/cse.o flag_move_all_movables ../gcc-2.7.2.2/loop.o flag_reduce_all_givs ../gcc-2.7.2.2/loop.o ld: fatal: Symbol referencing errors. No output written to gpc1 *** Error code 1 make: Fatal error: Command failed for target `gpc1' Most of these are defined in ../gcc-2.7.2.2/alias.o, so linking with that one (which _might_ be dangerous) gives: Undefined first referenced symbol in file flag_alias_check ../gcc-2.7.2.2/calls.o flag_argument_noalias ../gcc-2.7.2.2/alias.o flag_move_all_movables ../gcc-2.7.2.2/loop.o flag_reduce_all_givs ../gcc-2.7.2.2/loop.o these I can deal with. While I am pretty sure I can now produce an executable, you should carefully test it, as I did undocumented things to get it to work. fB ---------- Forwarded message ---------- Date: Mon, 19 May 1997 15:13:18 +0200 (MET DST) From: fB <frances(a)fis.unico.it> To: Vadim Denisyuk <denisyuk(a)fis.unico.it> Subject: GPC compiled, but it does not work. Apparently, the new version of GPC does not interact well with the Solaris linker/loader. This might be due to the modifications I introduced in order to compile it with G77, though[1]. The error I get while compiling the hello.pas test is: ========================================================================= % gpc test/standard_pascal/hello.pas ld: fatal: file test/standard_pascal/hello.pas: unknown type, unable to process using elf(3E) libraries ld: fatal: File processing errors. No output written to a.out ========================================================================= So it seems like gpc passes the wrong arguments to ld, something which did not happen with the previous version. Indeed g77 and gcc work perfectly with the Solaris-provided ld. On second thought... it seems like gpc passes everything unchanged to ld, without even attempting to compile anything. Indeed: ========================================================================= % ./gpc -c test/standard_pascal/hello.pas gpc: test/standard_pascal/hello.pas: linker input file unused since linking not done ========================================================================= So I probably messed up the command parser somewhere (see note). I'd install gpc in a completely separate directory with it's own straightforward version of gcc, but I already tried to do this with the previous version and, alas, g77 was (rather mysteriously) broken. I might real soon now experiment a little with doing this again in my copious free time. BTW, in the meanwhile I updated GCC/G77 to version 2.7.2.2.f.2 on all machines, and left 2.7.2.1 installed so that the old version of gpc still works. This _seems_ not to cause any problem right now. [1] This essentially reduces to linking gpc1 with ../gcc-2.7.2.2/alias.o and introducing the G77-specific options in toplev.c. I also had to explicitly #define some constants in a couple of places, though. As I could not be bothered to read and understand the source I obviously don't know what it's going on. -- fB ---------- Forwarded message ---------- Date: Mon, 19 May 1997 15:43:56 +0200 (MET DST) From: fB <frances(a)fis.unico.it> To: Vadim Denisyuk <denisyuk(a)fis.unico.it> Subject: Before you ask... I have done this (from the FAQ): A number of Unix configurations use their system's linker instead of GNU `ld'. Usually, GPC and GCC need a program called `collect2' before calling the system's `ld'. `collect2' is installed by GCC, and if you only install GPC, it will not find `collect2', and use the system linker directly, which will result in various linker errors. The solution is to copy `collect2' by hand from the GCC directory to the location where `gpc1' lives. -- fB ---------- Forwarded message ---------- Date: Mon, 19 May 1997 16:32:57 +0200 (MET DST) From: fB <frances(a)fis.unico.it> To: Vadim Aleksandrovich Denisyuk <denisyuk(a)fis.unico.it> Subject: Re: Before you ask... The new gpc compiles, but does not work. Seems like in order to make it to compile I screwed up the command parser. Sorry, but I exactly remade everything I made last time to compile V2.0 and it did not work anymore. Since I have one Pascal user and about thirty Fortran users, I'd rather break Pascal than Fortran. I will try again to check what the problem is, but I think that simply GPC is not yet able to peacefully coexist with G77. -- fB

1 0

New, experimental GPC version (pentium-gpc)
by Jan-Jaap van der Heijden 19 May '97

19 May '97

Hello all, I have something for the daring folks among you: a GPC, based on the latest Cygnus CDK snapshot. For those of you who don't know, the Cygnus snapshots are GCC development releases, so you could consider this to be a pre-2.8 GCC. I used GPC-alpha 970510. I tested it on linux and SGI irix and had no problems with it (yet). Now, GPC alpha releases are usually quite reliable, but this is a major change in code, so you could consider this _REALLY ALPHA_ ;-) It can do some cool things like pentium(pro) optimizations. I would love to hear from somebody who does lots of floating point on a pentium(pro) whether it's really is faster. Binaries for pentiumpro-intel-linux (RedHat 4.1) and mips-sgi-irix6.2 are available. The mips binary is not targeting 64bits because of the immaturity of mips64 support in GCC. The linux binary installs in /opt/cdkgpc-i970518. You can move it around, just make sure you don't install it over your existing GCC. URL: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/cygnus-970507 Apart from numerous "easy fixes" and manual patching, these changes were necessary because of changes in GCC internals: gpc-decl.c: build_complex(): extra argument. setop.c: clear_storage(): New last argument. Probably clear blocksize. set to 1. Not most efficient, but works. gpc-cccp.c: quick hacks to add: int c89 UCHAR is_space Known bugs: (1) "automake" is completely broken. Still looking for a fancy solution that enables us to share the `gcc' driver with GCC. (2) Some files not modified but reused from 2.7.2.x: gpc-cccp.c, gpc-lex.c Todo: All cygwin32 related patches were removed from GPC and must be put back in. Must check for cygwin32-beta18 compatibility. *maybe* do a djgpp version. BTW: I don't plan to maintain a seperate Cygnus CDK GPC source tree. You could consider this a techdemo: the effort and results will pay off once GCC 2.8 is released, because porting GPC will be much easier then. Happy hacking! JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

Re: alpha-970510: array problem.
by Peter Gerwinski 18 May '97

18 May '97

According to Jan-Jaap van der Heijden: > > It barfs on the "var N2: ^A;" declaration. The problem is solved. It was a trivial error. (-: If all bugs were like this ... :) To correct it, just add one line to `gpc-parse.y'. The diff is below. Thanks again, Jan-Jaap! 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] 8< --------------------------------------------------------------------------- --- gpc-parse.y Mon May 12 09:13:03 1997 +++ gpc-parse.y.new Sun May 18 17:36:34 1997 @@ -2533,6 +2533,7 @@ if (! flag_what_pascal || (flag_what_pascal & B_D_PASCAL)) lex_const_equal = 1; $<itype>$ = lex_caret; + lex_caret = 1; } ':' optional_qualifier_list type_denoter absolute_or_value_specification

1 0

Re: alpha-970510: array problem.
by Peter Gerwinski 18 May '97

18 May '97

According to Jan-Jaap van der Heijden: > > It barfs on the "var N2: ^A;" declaration. The reason is that GPC believes that the `^A' is Ctrl+A. I will fix that, thanks. 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

alpha-970510: array problem.
by Jan-Jaap van der Heijden 18 May '97

18 May '97

GPC alpha-970510 fails to compile this code: ----------------------------- program ArrayTest(output); type node = 0..4500; A = array[node] of integer; var N1 : A; N2 : ^A; begin writeln('OK'); end. ----------------------------- It barfs on the "var N2: ^A;" declaration. This used to work with previous releases of GPC. I can find no paragraph in the spec where it says that this declaration is valid, but I believe it is. Anyway, it BP likes it, and now `gpc -fborland-pascal' doesn't :-( BTW: This is the first bug detected by the automated compiler suite I'm writing, so I guess this proves the value of having such a thing. JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

BPCOMPAT - New "Borland" compatible UNITs for GPC !!!
by A.A. Olowofoyeku 17 May '97

17 May '97

Hi GPC folks! This is to announce the release of BPCOMPAT v 1.0, which has now been uploaded to agnes (in the "contrib" directory). If you are looking for greater Borland Pascal compatibility and/or you are looking for a big function library for GPC, you please download this package. You can get a copy from; ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bpcompat.zip This package serves a number of functions; 1. To provide UNITS for GPC in order to improve is compatibility with Borland Pascal. This package provides the following units for Borland Pascal ("BP") and Delphi compatibility; SYSTEM.PAS - BP compatible "SYSTEM" unit CRT.PAS - BP compatible CRT unit DOS.PAS - BP compatible DOS unit OBJECTS.PAS - BP compatible OBJECTS unit STRINGS.PAS - BP compatible STRINGS unit SYSUTILS.PAS - DELPHI compatible SYSUTILS unit GPCTYPES.PAS - various type definitions XSYSTEM.PAS - extra vital system stuff - not in BP GPCUTIL.PAS - Chief's Utilites unit - needed by some units NOTE: some of the BP and Delphi compatible units contain missing features, some things are quite different from the BP equivalents, and some of the routines do not work well. Differences are clearly marked in the source code, and those routines that do not work well are also clearly marked. 2. To provide a library of useful routines for GPC - some of them take the form of UNITs which import various routines from the C library - i.e., they are import units for various ".H" files in the C library. The routines which are not imported C functions are contained in GPCUTIL.PAS. Some of them provide compatibility with TurboPower Software's "Turbo Professional" library. Some of the functions in the converted C headers will not work properly - if you can make them work, fine. If not, please don't mail me - I can't make them work either. 3. To provide a shell program ("GPCC") for the GPC compiler. GPCC will accept parameters from the command line, and will also read parameters from an ascii file GPCC.CFG. All these will be passed on to the GPC compiler. GPCC also will detect whether the source file is a UNIT or a PROGRAM, and will pass extra parameters to the GPC compiler as required. GPCC is tailored to work a bit similarly to the Borland command line compiler (TPC or BPC). These are the import UNITs for various C header files; BIOS.PAS CONIO.PAS CTYPE.PAS DIR.PAS DOSH.PAS DPMI.PAS ERRORNO.PAS FCNTL.PAS IO.PAS PC.PAS PROCESS.PAS STATS.PAS STDIO.PAS STDLIB.PAS STRINGH.PAS SYS.PAS TIME.PAS UNISTD.PAS VALUES.PAS IMPROVEMENTS ------------ It is my hope that someone (or some people) will take this on from here, and improve on this package. Some of the functions could be written more efficiently. My main concern has been to provide working and reliable implementations of various parts of the BP runtime library - not to implement the functions in the most efficient way. It is also my hope that the package will be ported to other platforms. The current one has only been tested under DOS (DJGPP - but it should also be okay for EMX). However, I made sure that the SYSTEM.PAS unit uses only portable functions from the C library - so that should be easy to port to Linux and other Unix platforms. The DOS and CRT units are not portable to unix as they are. It would be nice if someone could port them to unix. If you can improve on the efficiency, and/or if you can implement some of the missing (or unreliable) routines, and/or if you can port these UNITs to other platforms, please feel free to do so!!! All I ask is this. Please, let this work be done in a coordinated fashion; a. If anyone is working on anything, please let me know *exactly* what you are doing or proposing to do, so that there will be no duplication of efforts; b. Please follow the conventions in the existing code, for comments, spacing, and so on; c. Please mark clearly any changes that you have made to my code, or to Peter's code; d. If you are working on the SYSTEM unit, please ensure that what you are doing it portable (e.g., by using only C functions that are portable across DOS, OS/2, Unix, etc.); e. When uploading your work, please upload everything in one package (.zip file), and put a version number on it. f. Please inform Peter and me when you are ready to upload a new version. BUGS ---- If you find bugs, please try to fix them - but please report them to me as well. If you fix them, please let me have a copy of the fix. Happy coding! Warmest regards, The Chief --------- Dr. Abimbola A. Olowofoyeku (The African Chief and The Great Elephant) Keele University, England (Email: laa12(a)cc.keele.ac.uk) Author of: Chief's Installer Pro v3.50 for Win16 and Win32 Homepage: http://ourworld.compuserve.com/homepages/African_Chief/

1 0

GNU Pascal for MachTen
by Gregory S. McNeilly 16 May '97

16 May '97

Hello - Has anyone ported GNU Pascal to MachTen? (MachTen is the Unix system operating with the MacOS on PowerMacs.) Please reply directly to me. Thanks for any information. Greg McNeilly ------------------- Gregory S. McNeilly ( gsm(a)ornl.gov ) ,---. Oak Ridge National Laboratory o \ POB 2008 <=====< >=====> Oak Ridge, TN 37831-6418 o / (423)574-5446 (FAX)574-0625 \___/ ------------------- http://casa.cad.ornl.gov/~gsm/

2 1

gpc-970510: source uploaded
by Peter Gerwinski 16 May '97

16 May '97

Hello, I was reported problems dealing with the many patches for the GPC alpha source, so I uploaded the source tree of gpc-970510 as a `.tar.gz' archive to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/. (Anyway I hope that we can enter beta stage soon.:) Yours, 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: Linking errors
by Peter Gerwinski 15 May '97

15 May '97

According to Vadim Aleksandrovich Denisyuk: > > This is a list of the unreferenced symbols I obtain linking the GPC > V2.0-alpha970510 against GCC 2.7.2.2.f.2 > [...] > emit_string_move gpc-util.o This is probably a "vpath" problem. The GPC FAQ says: 8< ---- begin (* FAQ *) ------------------------------------------------ Help! linking `gpc1' fails: `_emit_string_move' undefined (and more) If linking `gpc1' bombs out with an error message that looks like this: ld: Undefined symbol _emit_string_move _emit_string_pad _maybe_find_function_data _dbxout_set_type_status _version_flag *** Error code 1 make: Fatal error: Command failed for target `gpc1' you probably suffer from a VPATH make problem. A few GPC source files have counterparts with identical name in the GCC source directory. When you have built GCC in the GCC source directory and you are not using a recent version of GNU make this problem may occur. There are three solutions: 1. Get a recent version of GNU make. Version 3.74 or better is known to work. 2. Build GCC in a seperate directory instead of using the GCC source directory. 3. Manually delete these files from the GCC object directory: `stor-layout.o' `dbxout.o' `expr.o' `fold-const.o' `optabs.o' `convert.o' `function.o' `setop.o' `toplev.o' then resume `make'. 8< ---- end (* FAQ *) -------------------------------------------------- > P.S. Peter tvoy ruskiy is very GOOD Spasibo, :-) no ya znayu chto mnye nado uprazhnyat'cya ... 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

Linking errors (fwd)
by Vadim Aleksandrovich Denisyuk 15 May '97

15 May '97

This is a list of the unreferenced symbols I obtain linking the GPC V2.0-alpha970510 against GCC 2.7.2.2.f.2 I suspect most, if not all, of these errors are caused by the modifications caused by G77 0.5.20. I had a less serious version of this problem with GPC 2.0, GCC 2.7.2.1 and G77 0.5.18. That was related to new gcc optimization options introduced by G77, and unrecognized by the GPC front-end, and was easy to overcome. This one, at first glance, looks fare more serious. ============================================================================ Undefined first referenced symbol in file reg_known_equiv_p ../gcc-2.7.2.2/sched.o size_volatile gpc-util.o maybe_find_function_data gpc-parse.o emit_string_move gpc-util.o read_dependence ../gcc-2.7.2.2/sched.o record_base_value ../gcc-2.7.2.2/loop.o output_dependence ../gcc-2.7.2.2/sched.o version_flag gpc-module.o true_dependence ../gcc-2.7.2.2/cse.o anti_dependence ../gcc-2.7.2.2/sched.o reg_known_value ../gcc-2.7.2.2/sched.o emit_string_pad gpc-util.o init_alias_analysis ../gcc-2.7.2.2/cse.o dbxout_set_type_status gpc-decl.o ld: fatal: Symbol referencing errors. No output written to gpc1 *** Error code 1 make: Fatal error: Command failed for target `gpc1' ============================================================================= Yours, Vadim Denisyuk P.S. Peter tvoy ruskiy is very GOOD

1 0

New Alpha: gpc-970510
by Maurice Lombardi 15 May '97

15 May '97

I have downloaded the yesterday evening (14/05/97 23:..) modified version of alpha gpc-970510 for DJGPP v2.1 (zip file). The link problem is solved but the standalone info problem remains. I can read (gpc)Top with Rhide 1.2 but the standalone info barks no Top node. Looking to what could be anomalous in gpc.inf I have found they the last line of this file End Tag Table is repeated twice. I have used a UNIX-format editor to eliminate the second spurious line. With this modification standalone info (as well as with Rhide 1.2) no more complains. I cannot understand why. For the origin of this spurious duplication I have an hint: When Rhide finds an .inf file in DOS format (return/ line feed), it sometimes barks: File in Dos Format, and translate it into Unix format (linefeed alone). I have done the following when trying to understand the problem: I have translated gpc.inf (and gpc.i?) into DOS format, started Rhide which have barked, and have found when exiting that the files where again in Unix format, but with the last line repeated three times !!! I cannot understand the logic of that, because my gcc.inf are in DOS format and Rhide does not complain, and for exemple gpc.inf (now after the last modification), bison.inf and others are in unix format: only Robert can say what he does exactly to recognize the format and to change it. Hoping that it will help. Maurice Lombardi | Laboratoire de Spectrometrie Physique | Maurice.Lombardi(a)ujf-grenoble.fr Universite Joseph Fourier de Grenoble | tel: (33) (0)4 76 51 47 51 BP 87 | fax: (33) (0)4 76 51 45 44 38402 Saint Martin d'Heres Cedex FRANCE |

1 0

Re: gpc.inf doesn't work [Was: Installed Alpha 04/20 - Can't link]
by Peter Gerwinski 15 May '97

15 May '97

According to Achim Kalwa: > I have similar problems with the gpc-info files (gpc 950510) on my linux machine (2.0.29): > "info gpc" says: "no manual entry for gpc" > "info --file gpc.info" works fine. That's because the `dir' file in the info directory doesn't have an entry about gpc. You can insert it manually by editing `/usr/info/dir', e.g. by inserting a line * GPC: (gpc). Informations about the GNU Pascal compiler In principle we could include an updated `dir' into the GPC distribution, but this might make other programs barf, so we don't do it. 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: gpc.inf doesn't work [Was: Installed Alpha 04/20 - Can't link]
by Achim Kalwa 15 May '97

15 May '97

Hello! On Thu, 15 Mai 1997, Peter Gerwinski wrote: >According to Berend De Schouwer: [...] >> On a side note: >> gpc.inf doesn't work (no top node) >> But gpc.inf and gpc.i1 both reference and contain a top node. I >> can't see why "info --file gpc.inf" complains... >> >> gcc.inf/gcc.i1 look the same (at least in structure) and work. > >Something strange happened to the GPC documentation in that binary >distribution, sorry. I recompiled the info documentation on my system, >and now it's fine. I will correct this error when I will upload a new >binary DJGPP distribution once I will have solved that linking problem ... I have similar problems with the gpc-info files (gpc 950510) on my linux machine (2.0.29): "info gpc" says: "no manual entry for gpc" "info --file gpc.info" works fine. CU Achim

1 0

Re: Installed Alpha 04/20 - Can't link
by Peter Gerwinski 14 May '97

14 May '97

According to Berend De Schouwer: > On Sun, 11 May 1997, Peter Gerwinski wrote: > > I was sure that I am using v2.01, but I re-installed my `djdev201.zip' > > and `gcc2721b.zip', thus the new Alpha gpc-970510 should definitly (?) > > be v2.01. > > BUT, "gpc -v" says "2.0(2.7.2.1)" and not an alpha version number. > Did I install it right? I think so. Yes, you did. I forgot to set up the alpha version number for djgpp (where it must be done manually.) > gpc2.0 (non alpha) used to work fine. (* GPC 2.0 was compiled by Jan-Jaap, I think. ;*) > Well, gpc alpha 05/10 still says "ld: can't find djgpp.lnk" At least I can reproduce the error now by renaming "djgpp.lnk". As a workaround, I am posting my "djgpp.lnk" below; I will try to figure out what is going on here ... > "gcc -v" reports 2.7.2.1 and works. (compiles hello.c ;) > /djgpp/manifest has djdev201.mft, so I think I have djgpp v2.01. Same holds for my system. > I only started using djgpp after 2.01 came out. Is there any > other way to find out? (yes, seems like a newbie question ;) I join you in this question. > I checked my path, and djgpp's ld.exe seems to be the one that gets > executed (I also have fpk-pascal, which has an older version). > Is there any way I can check version numbers (compared to what?) of these? My BinUtils are 2.5.2 while README.1ST says that 2.7 is the current version for V2. Perhaps this is the problem? > On a side note: > gpc.inf doesn't work (no top node) > But gpc.inf and gpc.i1 both reference and contain a top node. I > can't see why "info --file gpc.inf" complains... > > gcc.inf/gcc.i1 look the same (at least in structure) and work. Something strange happened to the GPC documentation in that binary distribution, sorry. I recompiled the info documentation on my system, and now it's fine. I will correct this error when I will upload a new binary DJGPP distribution once I will have solved that linking problem ... According to Jan-Jaap van der Heijden: > To Peter: since this GPC is searching for this obsolete 'djgpp.lnk', I > assume you are indeed using v2.0. In that case you'd better upgrade to > 2.01 to stop this confusion. I believed I did, but obviously I didn't do it right. Some hints what I should do or check? 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] 8< ---- \djgpp\lib\djgpp.lnk ------------------------------------------------- OUTPUT_FORMAT("coff-go32") ENTRY(start) SECTIONS { .text 0x1000+SIZEOF_HEADERS : { *(.text) etext = . ; _etext = .; . = ALIGN(0x200); } .data ALIGN(0x200) : { djgpp_first_ctor = . ; *(.ctor) djgpp_last_ctor = . ; djgpp_first_dtor = . ; *(.dtor) djgpp_last_dtor = . ; *(.data) edata = . ; _edata = .; . = ALIGN(0x200); } .bss SIZEOF(.data) + ADDR(.data) : { *(.bss) *(COMMON) end = . ; _end = .; . = ALIGN(0x200); } }

2 1

New gpc-970510 for DJGPP (Was: Installed Alpha 04/20 - Can't link)
by Peter Gerwinski 14 May '97

14 May '97

According to Jan-Jaap van der Heijden: > > Unfortunately, GPC (gpc.exe) reads it's rules from "specs.gpc", which, in > Peter's alpha DJ binaries, still referred to "djgpp.lnk" I am uploading a new binary distribution for DJGPP which has Jan-Jaap's `specs.gpc' and simultaneously fixes the bug in the info documentation. (But it still versions to 2.0, not to 970610 as promised, because I was too lazy to recompile GPC.) > Since Peter probably installed djdev201 over djdev200, he probably has > both "djgpp.lnk" and "djgpp.djl", hence didn't notice the problem. Correct. But now I will remove `djgpp.lnk'. 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: Installed Alpha 04/20 - Can't link
by Peter Gerwinski 14 May '97

14 May '97

According to Jan-Jaap van der Heijden: > To Peter: since this GPC is searching for this obsolete 'djgpp.lnk', I > assume you are indeed using v2.0. In that case you'd better upgrade to > 2.01 to stop this confusion. I was sure that I am using v2.01, but I re-installed my `djdev201.zip' and `gcc2721b.zip', thus the new Alpha gpc-970510 should definitly (?) be v2.01. 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]

4 3

New Alpha: gpc-970510
by Peter Gerwinski 10 May '97

10 May '97

Hello! Here again is a new GPC alpha version. Changes since gpc-970420: General news: * `Absolute' now works in declaring statements, too. (Declaring statements are variable declarations in a function's statement part, a GPC extension. `Absolute' variables are a Borland extension supported by GPC.) * Initialization with `=' now has priority with respect to comparision. (Comparisions usually don't occur in initializers.) This means that BP-style typed constants now work as expected. In `--extended-pascal' mode, initialization with `=' is turned OFF, and comparision in initializers works like before. * Added/corrected some dialect-specific warnings. * With `--automake', non-Pascal input files may now occur before the first Pascal input file. * First fragments of a reference manual exist now: GPC's online Texinfo documentation now contains more-ore-less complete information about Integer types - sorted alphabetically from `Byte' to `Word'. * The alpha version number, "970510" for this release, is now output instead of "2.0" when `gpc' is invoked with the `-v' option. I hope this does not break anything ... Bug fixes: * `Page' now can be called with zero or one parameter. * Removed some wrong warnings from `-Wall'. * Parameter lists of methods now may contain a reference to the object they are methods of: MyObject = object Procedure Foo ( Var Bar: MyObject ); end (* MyObject *); * Units exporting different parts of the same object hierarchy work now. You still get a warning, but code works. (When a derived object is exported, complete information about the parent is exported, too. When two Units exported the same parent like this, GPC complained about incompatible definitions of the same identifier.) * Errorneous parent types in object declarations no more crash GPC. * Borland-style #27 character constants now work as the first thing in a line, too. (This bug usually showed up in `case' statements.) Borland Pascal: * Procedural variables work. They can be written like in Borland Pascal, or with the type names only. The same holds for pointers to functions. * ^A .. ^Z character constants work. (Even better than with BP itself.;) * The "link directive" (*$L foo.o *) or (*$L /usr/lib/libfoo.a *) works. As a GPC extension, you also can specify (*$L foo.pas *) or (*$L foo.c *): With `--automake', GPC compiles the specified source if necessary and links the object code. Without `--automake', GPC still links the `.o' file corresponding to the given source name. * `SizeOf' applied to object variables works now. The size is read at run time from the VMT. The object must be initialized. * `TypeOf' applied to object variables works now, too. As a GPC extension, you can explicitly assign a value to "TypeOf ( MyObj )" if extended syntax is ON (*$X+*). Extended Pascal: * Schemata work. (-: Well ... my tiny test programs work. This involves parameter passing and `new'ing pointers to undiscriminated Schemata. However I am not very experienced with Schemata, so I cannot give any warranty for them. (Which does not mean that I would give any other warranty, either expressed or implied, ... you know.;) Please help me to test them! I took special care that the String parameter stuff did not break due to the implementation of Schemata. (Read: Passing of String parameters might be broken now; please check.;-) One nice thing: `SizeOf' works with Strings and Schemata. When `p' is a pointer to a String or Schema, `SizeOf ( p^ )' looks into the String or Schema pointed to and determines the correct size at run time. The source - a diff against gpc-970420 - is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ together with binaries for DOS (DJGPP), DOS and OS/2 (EMX), Linux (ELF), and FreeBSD. Thanks to Abimbola A. Olowofoyeku, Frank Heckenbach, Jan-Jaap van der Heijden, Kevin A. Foss, and Markus Gerwinski for finding the bugs. And again: Is anybody interested to help to document all this? For example, to write a list of Extended Pascal [Borland Pascal] features which work [do not yet work] in GPC which replace the somehow outdated chapter "Extensions", "Extended Pascal", and "Borland Pascal" in the on-line manual? Or to complete and improve the description of the compiler options in the chapter "Invoking GPC"? If you do something in this direction, just post it here. Greetings, Peter Peter Gerwinski [670510], 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

Installed Alpha 04/20 - Can't link
by Berend De Schouwer 09 May '97

09 May '97

Hi I believe this was mentioned before... I installed alpha 4/20 (without making a backup, tch..) on djgpp v2 I can compile and get .o files, but the linking stage doesn't find djgpp.lnk (I assume gpc does "ld @djgpp.lnk") at some stage. I don't mind typing this myself, but I haven't got a sample .lnk file to work with (silly me ;). Any help will be appreciated. Cheers Berend De Schouwer P.S. gcc works fine.

2 1

Re: Portability questions (Arrays)
by Peter Gerwinski 08 May '97

08 May '97

According to Frank Heckenbach: > [...] > then 1 byte after a will be "wasted" though b could fit into it? It has to be > so if sizeof(a)=4, if someone does "move(...,a,sizeof(a))". Exactly. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Short Strings, Schema discriminants, UCSD Pascal
by Peter Gerwinski 08 May '97

08 May '97

According to Frank Heckenbach: > > > [...] present or planned for gpc? [...] > > Yes. > Planned, this is? Doesn't seem to be present (or different names?). Planned. Sorry, I unconsciously made a typical mathematician's mistake ... :-) 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: TFDDs - customizing `writeln' (Was: Legal Change in GPC ?)
by Frank Heckenbach 08 May '97

08 May '97

Peter Gerwinski wrote: > If somebody who knows C wants to implement this for GPC, here are > some ideas: > We are still looking for somebody who wants to implement a portable, > Borland-compatible `CRT'. (But our `Graph' Unit, "BGI2GRX", works on > Linux at least.:) I'd have some ideas for both, I only need one thing: time... -- perhaps in late summer/autumn, let's wait and see... -- unless someone wants to do it earlier. (Actually, I'd probably need some help on portability questions and other things, we'll see...) -- 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

2 1

Re: Portability questions (Arrays)
by Frank Heckenbach 08 May '97

08 May '97

Now, after Peter's and Berend's answers I'm a bit confused... Could someone clear things up for me, please? Note, I'm talking about gpc, not about other compilers or about the standard. Peter Gerwinski wrote: > Why is this so, e.g. with an array of something which has 3 bytes? > > > Program Test; > > Type > r = packed record > x: ShortWord; > y: Byte; > end (* r *); > > Var > x: packed array [ 1..1000 ] of r; > > begin > writeln ( SizeOf ( x ) ); > writeln ( SizeOf ( x [ 1 ] ) ); > end. > > > The output is 4000 and ... 4. To avoid alignment problems in an "array > of r", the record `r' has size 4, not 3. BTW: Does this mean if you have var a:r; b:byte; then 1 byte after a will be "wasted" though b could fit into it? It has to be so if sizeof(a)=4, if someone does "move(...,a,sizeof(a))". -- 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

Short Strings, Schema discriminants, UCSD Pascal (Was: Modifying string length?)
by Frank Heckenbach 08 May '97

08 May '97

Peter Gerwinski wrote: > > BP 7.0 allows this via High(s) -- is something like BP's High and Low > > functions (to give the lower and upper bounds of arrays and subrange types) > > present or planned for gpc? [...] > > Yes. Planned, this is? Doesn't seem to be present (or different names?). -- 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

Cancel from the List
by Walter Schaufelberger 06 May '97

06 May '97

Please delete me from the gpc member list. The user for this compuserve adress has changed and im not interested in gpc W. Schufelberger

1 0

Short Strings, Schema discriminants, UCSD Pascal (Was: Modifying string length?)
by Peter Gerwinski 05 May '97

05 May '97

According to Frank Heckenbach: > > [...] Then perhaps it would be > useful to allow the same syntax also for ShortStrings (additionally), just > as if ShortString[n] was declared as: > > record > case boolean of > false:(CurrentLength:byte); > true:(string:array[0..n] of char); > end; > > Also, it could be good to provide a (read-only) "pseudo field" Capacity. > [...] > These two things would make ShortStrings more similar to (and often > exchangeable with) LongStrings, without giving up BP compatibility. Good ideas, but a lot of work ... > (BTW: LongStrings' Capacity is always read-only, isn't it?) It is not. Probably it should be - somebody knows? And for other schema discriminants? > BP 7.0 allows this via High(s) -- is something like BP's High and Low > functions (to give the lower and upper bounds of arrays and subrange types) > present or planned for gpc? [...] Yes. > [...] So, perhaps better forget about the #0 with ShortStrings, and add > it when converting to other strings... I think that's the way to go. > But UCSD was non-standard, too, wasn't it? Just out of curiosity, it doesn't > really matter to me. UCSD Pascal was developed at the University of California San Diego (UCSD), not by a company, that's why I consider it as a well-defined standard, although no ISO standard. I have read about a company "SofTech" distributing UCSD Pascal, and I got mine from Apple as "Apple Pascal". If somebody has some more exact information, I would be glad to know. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Portability questions (Arrays)
by Berend de Boer 03 May '97

03 May '97

Frank Heckenbach wrote: >Two questions about portability of properties of arrays: >1. Is it safe to assume -- for all platforms, including possible future > ones -- that SizeOf(a) = ((Ord(y)-Ord(x)+1) * SizeOf(t)? No. > 2. Is it safe to assume that > Integer(@a[p])-Integer(@a[q]) = (p-q) * SizeOf(t)? No. > (Is it generally allowed to cast a pointer into an integer, > in the first place?) No. Groetjes, Berend.

1 0

Re: ClrScr
by Peter Gerwinski 03 May '97

03 May '97

According to Herbert Voss: > > how can I clear the screen under gpc? Just like > Borlands ClrScr. On the DOS/DJGPP platform, use `ClrScr' from the `CRT' Unit of the "BPcompat" package, available at ftp://kampi.hut.fi/jtv/gnu-pascal/contrib/bpcompat.zip ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bpcompat.zip You can also try the portable `BO5' library, available at ftp://kampi.hut.fi/jtv/gnu-pascal/contrib/bo5/ ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bo5/ `BO5' has a `Displays' Unit which implements a `ClearScreen' procedure which does essentially the same as `ClrScr'. We are still looking for somebody who wants to implement a portable, Borland-compatible `CRT'. (But our `Graph' Unit, "BGI2GRX", works on Linux at least.:) 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

BP-style ^X character constants
by Peter Gerwinski 03 May '97

03 May '97

Hello, I proudly announce that the next alpha version of GPC will understand BP-style character constants: ^A means chr ( 1 ) i.e. Ctrl+A, etc. Thanks to GPC's context-sensitive lexical analyzer, they work even better than in BP. GPC just compiled Type X = ^Y; (* Forward pointer reference *) Y = array [ ^A..^Z ] of ^Z; (* An array of pointers to Z *) Z = ^A..^Z; (* Subrange chr(1)..chr(26) *) Now try to compile this with Borland Pascal 7.0 ... ;-) Hooray, 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

TFDDs - customizing `writeln' (Was: Legal Change in GPC ?)
by Peter Gerwinski 03 May '97

03 May '97

According to Frank Heckenbach: > > Indeed, I'd like to have something like this in gpc, too. I'm not at all > familiar with the internals of "Text" files (or other files) in gpc. > (ISTR, it has something to do with "bindable" variables, but I don't know > much about those, either.) > > [...] > > The particular syntax (and other things) BP uses for this is, IMHO, not very > nice (it was introduced after the "good days" of Borland, but before the > introduction of OOP, which could have simplified things), so I don't vote > for copying BP's mechanism. But any way to do such things would be good. If somebody who knows C wants to implement this for GPC, here are some ideas: GPC's run time system (RTS) defines a function `_p_write' which is responsible for all output to text files. The C source is in `rts/rts-write.c'. I already modified this function to call `cprintf' instead of `printf' on the DOS platform if the variable `_p_directvideo' has a nonzero value. This is done through some preprocessor macros PRINTF1, ... PRINTF4, CFWRITE and serves the purpose to make a `CRT' Unit for DOS possible. If you replace my macro calls by a call to `sprintf' followed by an indirect call to an output function, we've got it. (Note that Pascal allows `chr ( 0 )' characters in Strings.) Happy hacking, 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Portability questions (Arrays)
by Peter Gerwinski 03 May '97

03 May '97

According to Frank Heckenbach: > > 1. Is it safe to assume -- for all platforms, including possible future > ones -- that SizeOf(a) = ((Ord(y)-Ord(x)+1) * SizeOf(t)? I first thought that this would not be the case due to alignment problems, but ...: That's *exactly* the way how GPC calculates the size of an array. Why is this so, e.g. with an array of something which has 3 bytes? Program Test; Type r = packed record x: ShortWord; y: Byte; end (* r *); Var x: packed array [ 1..1000 ] of r; begin writeln ( SizeOf ( x ) ); writeln ( SizeOf ( x [ 1 ] ) ); end. The output is 4000 and ... 4. To avoid alignment problems in an "array of r", the record `r' has size 4, not 3. I conclude that the assumption is safe. > 2. Is it safe to assume that > Integer(@a[p])-Integer(@a[q]) = (p-q) * SizeOf(t)? Yes, for the same reason. If the "natural" size of `t' would cause alignment problems, `t' is blown up by GPC. > (Is it generally allowed to cast a pointer into an integer, > in the first place?) I think so. The GNU coding standard says about GCC's (and thus GPC's) behaviour: You can assume that all pointers have the same format, regardless of the type they point to, and that this is really an integer. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

page procedure bug?
by Kevin A. Foss 03 May '97

03 May '97

Hello, The discussion of 'clrscr' caused me to look into GPC's support of the page procedure. [On all of the Pascal variants I've used in the past -- I've never used any Borland variant -- 'page' would effectively clear the screen.] While GPC on the other hand seems to follow the standard literally and output just a FF (ASCII 12). No problem there, but the problem is that GPC gives a parse error if use just 'page' but accepts 'page(output)'. My reading of the standard is that page with no parameters should assume standard output, at least if output is explicitly declared in the program heading. (ISO 7185 6.9.5) E.g. this program should compile: program pagetest(output); begin page; end. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

ClrScr
by Herbert Voss 03 May '97

03 May '97

Hello, how can I clear the screen under gpc? Just like Borlands ClrScr. Thanks Herbert

1 0

Re: Modifying string length?
by Frank Heckenbach 02 May '97

02 May '97

Peter Gerwinski wrote: > > s:='' should do the same. (BP optmizes this to just setting the length to 0, > > I hope gpc does as well.) > > It does. (But better check it, too - I already was wrong once with > statements of this type.;-) Yes, it does. I checked it. It even does "s:='...'" where '...' is a constant string with length<=14 without any loops or calls. > > I think it should (at least with {$X+} or such), because it's the only way > > to translate some kinds of procedures -- unless one wants to limit such > > procedures to borland-like short strings. > > Long strings: "S.length:= ...". Short strings: "S [ 0 ]:= chr ( ... )". ^^^^^^ ...or rather CurrentLength, as you said before. Then perhaps it would be useful to allow the same syntax also for ShortStrings (additionally), just as if ShortString[n] was declared as: record case boolean of false:(CurrentLength:byte); true:(string:array[0..n] of char); end; Also, it could be good to provide a (read-only) "pseudo field" Capacity. (BTW: LongStrings' Capacity is always read-only, isn't it?) BP 7.0 allows this via High(s) -- is something like BP's High and Low functions (to give the lower and upper bounds of arrays and subrange types) present or planned for gpc? Then the compiler could just translate "s.Capacity" to "High(s)" in the case of ShortStrings. These two things would make ShortStrings more similar to (and often exchangeable with) LongStrings, without giving up BP compatibility. > > The question is, should the #0 be added for short strings as well? > > If Length=Capacity, it's impossible, but otherwise??? > > We could increase the space allocated for a short string by 1, but this > would break compatibility to UCSD and Borland Pascal. So better ignore > this and live with "String [ 255 ]" having only a capacity of 254 in fact. No, I guess this could break some programs, too. BTW: The problem is also there for Length=Capacity<=255: either we'd have Sizeof(String[n])=n+2 or (Capacity of String[n])=n-1 -- both could lead to problems. So, perhaps better forget about the #0 with ShortStrings, and add it when converting to other strings... > > Isn't it good when non-standard compilers (BP) use non-standard syntax? :-) > > I would not call this "non-standard" since this - like many other things, > e.g. Units - was not invented by Borland but by UCSD. But UCSD was non-standard, too, wasn't it? Just out of curiosity, it doesn't really matter to me. -- 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: Legal Change in GPC ?
by Frank Heckenbach 02 May '97

02 May '97

Christian Wendt wrote: > PG>> not "impossible"- you only got to reinvent the wheel and write to > PG>> $b80000... _big_ loss in portability & comfort (no easy to call writeln. > PG>Nevertheless this will remain my preferred method in BO5. The fastest > PG>thing you can imagine on the DOS platform. > hmm. is the type of "file" specified in the ISO /Extended? > would it be possible to define it similar to TP/BP? > there's a list of procedures inwith the file "record" - they specify the > functions to init/flush/writebuffer/readbuffer (theoretical you could do > the same with an object...) I assume you mean BP's TFDD (Text File Device Drivers). BTW: It's for "Text", not for typed are untyped files (though there's actually no reason why it shoudln't apply to them, too, except that BP's doesn't). Indeed, I'd like to have something like this in gpc, too. I'm not at all familiar with the internals of "Text" files (or other files) in gpc. (ISTR, it has something to do with "bindable" variables, but I don't know much about those, either.) First a short explanation for those not familiar with BP: Basically, TFDDs allow the programmer to assign procedures with the following semantics to a "Text" variable to be used instead of file I/O: Open: Input: File mode (Reset / Rewrite / Extend (aka Append)) Read: Input: Buffer size Output: Actual size read (<= Buffer size); the value 0 signals an EOF -- but perhaps it would be better to have a separate EOF function (e.g. for things like serial ports that may have no data at one time, but get some data later). Data that were read (in the buffer) Write: Input: Data in buffer Size Flush: (the same as Write, except that it should additionally "physically flush the file", as far as that makes sense -- I can't remember any examples where this did anything different than Write) Close: - All procedures also have an "error code" as Output to signal un-/successful completion of the operation. The TFDD can have a local data space (in BP: up to 16 bytes, AFAIR) -- local to the file to distinguish different "instances" of files assigned to a particular TFDD. (Here we see the similarities to objects...) The big advantage is that one can do a Write[ln]/Read[ln] with all its possibilites and have the data automatically "piped" to certain routines. Sure, one could achieve the same in gpc with WriteStr/ReadStr and passing the string to the routines, but (a) it's not completely as easy (2 statements instead of one), (b) managing the "local data" would require additional effort everywhere this is used, (c) it's not TP compatible..., (d) a TFDD can be used transparently (e.g. a variable assigned to a TFDD can be passed to any procedure that wants a "Text" file). The particular syntax (and other things) BP uses for this is, IMHO, not very nice (it was introduced after the "good days" of Borland, but before the introduction of OOP, which could have simplified things), so I don't vote for copying BP's mechanism. But any way to do such things would be good. In fact, many of my units use TFDDs, and I can't see a "good" way of porting programs that use them to gpc (only perhaps with heavy use of the preprocessor, but I'd not like to do it like that). I'd not complain at all if it was done with OOP (i.e. "Text" would be an object type, the "procedure" above would be methods, the local data would be the fields of the object), the main thing is that the object could be used in simple Read[ln]/Write[ln] statements. Any chances to do something like this with reasonable effort? -- 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

Portability questions (Arrays)
by Frank Heckenbach 02 May '97

02 May '97

Hi everyone! Two questions about portability of properties of arrays: Let's assume a:array[x..y] of t (not a packed array). 1. Is it safe to assume -- for all platforms, including possible future ones -- that SizeOf(a) = ((Ord(y)-Ord(x)+1) * SizeOf(t)? 2. Is it safe to assume that Integer(@a[p])-Integer(@a[q]) = (p-q) * SizeOf(t)? (Is it generally allowed to cast a pointer into an integer, in the first place?) -- 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: What is standard, and what isn't?
by Peter Gerwinski 02 May '97

02 May '97

According to Nils Bokermann: > How do you want to compare structured variables? Compare member by > member? Yes. Except with types where we know that a simple byte compare is sufficient. > I knew a very fine programming language (ELAN) in which it was possible > to define your own operator (`=', `<>' or whatever you wanted). Is it > possible to have this as an extension to Pascal? It's a PXSC extension which is already in GPC: Operator = ( x, y: MyType ) result: Boolean; begin (* MyType = MyType *) result:= ( x.foo = y.foo ) and ( x.bar = y.bar ) or whatever; end (* MyType = MyType *); 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Modifying string length?
by Peter Gerwinski 02 May '97

02 May '97

According to Frank Heckenbach: > > s:='' should do the same. (BP optmizes this to just setting the length to 0, > I hope gpc does as well.) It does. (But better check it, too - I already was wrong once with statements of this type.;-) > I think it should (at least with {$X+} or such), because it's the only way > to translate some kinds of procedures -- unless one wants to limit such > procedures to borland-like short strings. Long strings: "S.length:= ...". Short strings: "S [ 0 ]:= chr ( ... )". > The question is, should the #0 be added for short strings as well? > If Length=Capacity, it's impossible, but otherwise??? We could increase the space allocated for a short string by 1, but this would break compatibility to UCSD and Borland Pascal. So better ignore this and live with "String [ 255 ]" having only a capacity of 254 in fact. > Currently the length could probably be changed by writing to > s[1-SizeOf(Integer)] .. s[0] -- but I really don't want to try that... :-| No. This will only work for lenghts below 256 and on big-endian machines. Better cast the String to a record (read: cast a pointer to the String to a pointer to a record). > BTW: Does the standard require range checking (or does it say anything about > it at all)? Yes, AFAIK. > And with {$X-} they don't work at all, you mean? Seems ok. > And the same for packed records? Yes. > Isn't it good when non-standard compilers (BP) use non-standard syntax? :-) I would not call this "non-standard" since this - like many other things, e.g. Units - was not invented by Borland but by UCSD. > BTW: String[n] with n>255 wouldn't work at all then? Yes. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: stdin/stdout
by Peter Gerwinski 02 May '97

02 May '97

According to Andreas Bauer: > > can you please explain me how to use the stdin/stdout with gpc? > The compiler does not seem to know these. The "legal" way is to use ordinary `read', `readln', `write', and `writeln' operations. Note that `read' returns a space at the end of a line, not a chr ( 10 ) or chr ( 13 ), and that `eoln ( Input )' is `true' instead. > It *does* work when stdin/stdout are connected to the terminal, but > when using pipes it seems not to work. It should work except that the first char is "eaten" by the GPC RTL. See the thread "[BUG] GPC - a char killer?" on 7. and 11. April in this list for reasons and a workaround. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re^5: Legal Change in GPC ?
by Peter Gerwinski 02 May '97

02 May '97

According to Christian Wendt: > > PG>The same stuff as in Borland's CRT, isn't it? > Hmm. no - several stuff. > move; > declaration of byte... > paramstr,paramcount > (the date is 27.10.96) - seems to be an extract of tools/system.pas of BO5 We are speaking of different Units: You mean `bpcompat.pas' while I am speaking of `bpcompat.zip' which contains `system.pas', `crt.pas', etc. > hmm. is the type of "file" specified in the ISO /Extended? You mean the internal structure of the `file' type? No. > would it be possible to define it similar to TP/BP? > there's a list of procedures inwith the file "record" - they specify the > functions to init/flush/writebuffer/readbuffer (theoretical you could do > the same with an object...) It's defined in a quite different way. The record contains a lot of interesting information about the file, but no `hooks'. The actual input/output is done via `ordinary' functions written in C. But be invited to implement those `hooks' in the GPC RTS. > PG>Of course. But a CRT Unit could use these sequences to access the > PG>terminal in a portable way. > Yes... transparent for the programmer... Everything is transparent for the programmer since you have the source code of everything. :-) 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

problem with gpclib.a (alpha-version)...
by Peter Gerwinski 01 May '97

01 May '97

According to Andreas Eckleder: > > ...i've got some problem with the library file of the actual (?!?) > alphaversion of gnu-pascal... (* Du meinst: "current" version? ;*) Obviously not - see below. > [...] > > the other problem i realized with this alpha-version is that i couldn't > manage to use the inline assembler. > i only only got a message telling me function asm() not beeing existent. This was a but in some old alpha versions of GPC which is fixed now. The current version is gpc-970420 (see my signature). BTW, the GPI file format changes with (almost) each version, so please recompile your units after upgrading. > because of this strong behavior i use the gpc2.0 compiler with the alpha- > libraries...perhaps THIS is the reason why the function above doesn't > work, > but i am not quite sure about that... (* That's what alpha versions are for: To find all bugs before releasing it to the public. :*) Please try again with gpc-970420 - or with gpc-9705?? ... perhaps this weekend ... 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Modifying string length?
by Frank Heckenbach 01 May '97

01 May '97

The African Chief wrote: > >But how would you translate references to s[0] in BP then? I know, there > >shouldn't be any in most programs, but sometimes it can be useful, e.g. for > >efficiency. But it's ok for me if it's only enabled with {$X+}, see below. > > "s[0] := ..." is okay. But you couldn't do that with long strings since their length isn't stored in [0], but in .length. So there are cases where write access to .length is needed, that's what I meant. > I do that myself sometimes (but only to set the length to zero). s:='' should do the same. (BP optmizes this to just setting the length to 0, I hope gpc does as well.) > "length(s) := ...." > or "s.length := ..." > > - which shouldn't compile (if at all), when using "--borland-pascal". I think it should (at least with {$X+} or such), because it's the only way to translate some kinds of procedures -- unless one wants to limit such procedures to borland-like short strings. > >Does this mean strings will always have an additional trailing #0? Do the > >string routines currently support this (i.e. automatically add a #0 at the > >end; but they should not recognize #0 as a terminator, but only rely on the > >length field)? That would be good, because it simplifies converting a string > >into a CString a lot (just "CString(@s[1])", right?). > > Delphi 2 does this with long strings (I think). If we are going to do it, > perhaps it should only be done for long strings as well? > > However, what happens when you want to add a string to > the end of it? Check this example, and look at the ouput > under Borland; > > program Fred; > var > s,s1:string[40]; > begin > s := 'Fred Smith'+#0; > s1 := s + 'is okay'; > writeln ( s1 ); > {prints "Fred Smith is okay" - where did the space before "okay" > come from? I didn't want or put it there - viz; problem with trailing "#0"} > end. As Peter has already pointed out, an implicit #0 would not behave like this. I suppose this would be achieved by having the length not include the #0. So the internal representation of 'foo' would be something like: Long string: Capacity:...; Length: 3; string: ('f','o','o',#0,...) Short string: (#3,'f','o','o',#0,...) The question is, should the #0 be added for short strings as well? If Length=Capacity, it's impossible, but otherwise??? BTW: Your example raises the "problem" that if you have a string with one or more #0 in it, and convert it to a CString, the CString will be shorter than expected. But I think there's nothing to be done about it. If one wants to convert a string to a CString, one just must not put any #0 in it... Peter Gerwinski wrote: > > But how would you translate references to s[0] in BP then? I know, there > > shouldn't be any in most programs, but sometimes it can be useful, e.g. for > > efficiency. But it's ok for me if it's only enabled with {$X+}, see below. > > That's one reason why `StortString's should be implemented - which will > have "s[0]". But this job doesn't have high priority for me ... As I said above, it would (currently) suffice for me if "s[0]:=..." could be translated to "s.CurrentLength:=..." for long strings. But at the moment, it can't be translated at all. The BP syntax "s[0]" is, IMHO, not very good, so it should not be supported (emulated) for long strings. > > Sounds good! {$X} is a local switch, isn't it (so one can turn it on and off > > around code that needs it, and be safe from accidents elsewhere). It would be > > even better than BP (where accidental writes to s[0] are not even detected > > by range checking). :-) > > As long as GPC has no range checking at all ... I know... Currently the length could probably be changed by writing to s[1-SizeOf(Integer)] .. s[0] -- but I really don't want to try that... :-| BTW: Does the standard require range checking (or does it say anything about it at all)? > "CurrentLength"? Why not. > What about this: With (*$X+*), addresses of packed array members are > only rejected if they don't lie on a byte boundary, and otherwise they > work? And with {$X-} they don't work at all, you mean? Seems ok. And the same for packed records? > Another idea, perhaps even better: let "String ( 255 )" or > "LongString ( 255 )" denote an Extended Pascal (long) string, but > "String [ 255 ]" or "ShortString [ 255 ]" an UCSD Pascal (short) > string? Like this, both Extended Pascal and Borland Pascal programs > will just compile. Needless to say that `--extended-pascal' will > switch off "String [ 255 ]" and `--borland-pascal' will switch off > "String ( 255 )" ... Isn't it good when non-standard compilers (BP) use non-standard syntax? :-) BTW: String[n] with n>255 wouldn't work at all then? Seems ok to me. -- 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

Please delete me from your mailing list
by Cristian Sala 01 May '97

01 May '97

Please cancel my registration to your mailing list tank you Cristian Sala

1 0

What is standard, and what isn't?
by Peter Gerwinski 01 May '97

01 May '97

Hello, perhaps somebody can help to clarify the following two questions: 1) Is the comparision with `=' or `<>' of structured variables okay in ISO Pascal? ISO 10206 6.8.3.5 only says that the types to be compared must be compatible. If not, this might be a reasonable extension (already offered by some compilers, *not* including Borland Pascal;). 2) In GPC strings, the schema discriminant "Capacity" is accessible as a "record field" of the string. Is this okay by ISO 10206, and should it be done for other schemata this way, too? And how to tread the "length" field of a string? ISO 10206 6.4.3.3 does not say anything about that. I could imagine the string schema type to be something similar to Type String ( Capacity: Integer ) = record length: Integer; String: packed array [ 1..Capacity ] of Char; end (* String *); except that the "String" field is automatically dereferenced. Thanks for your help, 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Modifying string length?
by Peter Gerwinski 01 May '97

01 May '97

According to The African Chief: > > However, what happens when you want to add a string to > the end of it? Check this example, and look at the ouput > under Borland; > > program Fred; > var > s,s1:string[40]; > begin > s := 'Fred Smith'+#0; > s1 := s + 'is okay'; > writeln ( s1 ); > {prints "Fred Smith is okay" - where did the space before "okay" > come from? I didn't want or put it there - viz; problem with trailing "#0"} > end. It's no space; it's a #0, as you requested. The above is an *explicit* trailing #0. It is part of the string and must not vanish when adding another string. The *implicit* trailing #0 to be appended for CString compatibility *will* vanish; however the program above will still produce the same result. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Modifying string length?
by The African Chief 01 May '97

01 May '97

On Thu, 1 May 1997 13:40:14 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to The African Chief: >> >> However, what happens when you want to add a string to >> the end of it? Check this example, and look at the ouput >> under Borland; >> >> program Fred; >> var >> s,s1:string[40]; >> begin >> s := 'Fred Smith'+#0; >> s1 := s + 'is okay'; >> writeln ( s1 ); >> {prints "Fred Smith is okay" - where did the space before "okay" >> come from? I didn't want or put it there - viz; problem with trailing "#0"} >> end. > >It's no space; it's a #0, as you requested. Yes. >The above is an *explicit* trailing #0. It is part of the string and >must not vanish when adding another string. True. >The *implicit* trailing #0 to be appended for CString compatibility >*will* vanish; however the program above will still produce the same >result. That is okay then. I just thought that the point needed to be made, that there could be a problem with a trailing #0. If the compiler makes the ones that it adds to vanish away, the problem disappears. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: Modifying string length?
by Peter Gerwinski 01 May '97

01 May '97

According to Frank Heckenbach: > > But how would you translate references to s[0] in BP then? I know, there > shouldn't be any in most programs, but sometimes it can be useful, e.g. for > efficiency. But it's ok for me if it's only enabled with {$X+}, see below. That's one reason why `StortString's should be implemented - which will have "s[0]". But this job doesn't have high priority for me ... > But, a *packed* array? If I remember correctly, it's not possible to get an > address of a component of a packed record/array (because they could possibly > not start on a byte boundary) (but when trying it, I encountered some > problems, see below). Actually, packed arrays of chars are the same as non-packed arrays. Right now, GPC does not check whether you take the address of a packed array member, so it works with packed arrays of chars, and produces nonsense with Booleans (see below). > If this is so (and won't be changed so that it is possible to get an address > of those components that actually start on a byte boundary), I'd vote for an > un-packed array here. BTW: Is there any advantage in packing here? AFAICS (at > least with Linux), an un-packed array of char is exactly as big as a packed > one. Is this not always so? Extended Pascal requires "packed" here. > Does this mean strings will always have an additional trailing #0? Do the > string routines currently support this (i.e. automatically add a #0 at the > end; but they should not recognize #0 as a terminator, but only rely on the > length field)? That would be good, because it simplifies converting a string > into a CString a lot (just "CString(@s[1])", right?). It's not like that, but perhaps it *should* be like that ... > Sounds good! {$X} is a local switch, isn't it (so one can turn it on and off > around code that needs it, and be safe from accidents elsewhere). It would be > even better than BP (where accidental writes to s[0] are not even detected > by range checking). :-) As long as GPC has no range checking at all ... \begin{sigh} Following the tradition of a large well-known software company, I could now advertise for GPC by announcing that GPC's range checking, once it will be implemented, will be *much* better than that of Borland Pascal. Although I am sure that this will be true, I don't want to join this vaporware marketing method. \end{sigh} > BTW: Should the field be called "length" like the function length? It might > give conflicts with "with" statements ("with" works with schemata, doesn't > it?) as in: (It does. I thought it would not do.) You are right. It must be renamed then. > Perhaps something like str_length or such? "CurrentLength"? > As I said above, I had some problems with the new packed arrays. I tried the > following: Ah - the first bugs with packed arrays. I will look at them, thanks. What about this: With (*$X+*), addresses of packed array members are only rejected if they don't lie on a byte boundary, and otherwise they work? > Should the "()" be allowed here [after `@'] (though not required)? > FWIW, TP5.5 doesn't allow them, BP7.0 does... I will have a look at that, too. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: ShortStr
by Peter Gerwinski 01 May '97

01 May '97

According to Kim Robert Blix: > > When it comes to compability on the issue of strings, would'nt it be > natural to call the short string version just "string" and the long > one "longstr", instead of the other way around? This would break compatibility to the Extended Pascal standard. But it could be reasonable to do it like you wrote in `--ucsd-pascal' and `--borland-pascal' mode. What about the following: Make `LongString' denote Extended Pascal string schemata, and `ShortString' denote UCSD/Borland Pascal strings; let `String' be the same as `LongString' in default mode but the same as `ShortString' in Borland Pascal mode; finally introduce more options `--short-strings' and `--long-strings' to change these defaults? Another idea, perhaps even better: let "String ( 255 )" or "LongString ( 255 )" denote an Extended Pascal (long) string, but "String [ 255 ]" or "ShortString [ 255 ]" an UCSD Pascal (short) string? Like this, both Extended Pascal and Borland Pascal programs will just compile. Needless to say that `--extended-pascal' will switch off "String [ 255 ]" and `--borland-pascal' will switch off "String ( 255 )" ... Anyway, this is a long-term plan. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Modifying string length?
by The African Chief 01 May '97

01 May '97

On Thu, 1 May 1997 04:12:47 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >The African Chief wrote: > >> >> It would not be too difficult to make "MyStr.length" and "MyStr.String" >> >> accessible "record fields" of strings. Would it be desireable? >> > >> >Yes! (At least length; the String part is accessible anyway with s[n].) >> > >> >> I am >> >> not sure how this fits into the standard ... >> > >> >I'm not, either. If it conflicts, it should be disabled with >> >"--extended-pascal", I suppose. >> >> It should be disabled, with "-borlland-pascal" as well. > >But how would you translate references to s[0] in BP then? I know, there >shouldn't be any in most programs, but sometimes it can be useful, e.g. for >efficiency. But it's ok for me if it's only enabled with {$X+}, see below. "s[0] := ..." is okay. I do that myself sometimes (but only to set the length to zero). What I was referring to was something like; "length(s) := ...." or "s.length := ..." - which shouldn't compile (if at all), when using "--borland-pascal". >Does this mean strings will always have an additional trailing #0? Do the >string routines currently support this (i.e. automatically add a #0 at the >end; but they should not recognize #0 as a terminator, but only rely on the >length field)? That would be good, because it simplifies converting a string >into a CString a lot (just "CString(@s[1])", right?). Delphi 2 does this with long strings (I think). If we are going to do it, perhaps it should only be done for long strings as well? However, what happens when you want to add a string to the end of it? Check this example, and look at the ouput under Borland; program Fred; var s,s1:string[40]; begin s := 'Fred Smith'+#0; s1 := s + 'is okay'; writeln ( s1 ); {prints "Fred Smith is okay" - where did the space before "okay" come from? I didn't want or put it there - viz; problem with trailing "#0"} end. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: ShortStr
by The African Chief 01 May '97

01 May '97

On Thu, 1 May 1997 12:29:09 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: > finally introduce more options >`--short-strings' and `--long-strings' to change these defaults? I think this is the key! Introduce a "--short-strings" ( or "{$H-}" ) or whatever, to turn off the default (which should be long strings - because it ensures more compatibility with EP and Delphi 2). I believe that Delphi 2 automatically terminates long strings with a "Chr(0)". Perhaps we should do this as well? Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: ShortStr
by Berend de Boer 01 May '97

01 May '97

"Kim Robert Blix" wrote: >When it comes to compability on the issue of strings, would'nt it be >natural to call the short string version just "string" and the long >one "longstr", instead of the other way around? I think natural should mean the one with the least restrictions. Integers are 32-bit, not 16-bit, strings are unlimited, instead of limited, etc, etc. And this is more compatible with Delphi 2. Groetjes, Berend.

1 0

exit; ????
by skye 01 May '97

01 May '97

Is Exit not included in GPC? i.e. program test; procedure t1(a:integer); begin writeln('hello1'); if a = 1 then exit; writeln('hello2'); end; begin writeln('hello'); t1(1); t1(0); writeln('hello3'); end. should produce: hello hello1 hello1 hello2 hello3 but I get Undefined Indentifier 'Exit' I tried using return; and that works. I posted this question to the comp.lang.pascal NG and had someone from Borland tell me that Exit should do the trick (I didn't say I wasn't using TP tho). Is exit a Borland thing? -SC

2 1

Re: Modifying string length?
by Frank Heckenbach 01 May '97

01 May '97

The African Chief wrote: > >> It would not be too difficult to make "MyStr.length" and "MyStr.String" > >> accessible "record fields" of strings. Would it be desireable? > > > >Yes! (At least length; the String part is accessible anyway with s[n].) > > > >> I am > >> not sure how this fits into the standard ... > > > >I'm not, either. If it conflicts, it should be disabled with > >"--extended-pascal", I suppose. > > It should be disabled, with "-borlland-pascal" as well. But how would you translate references to s[0] in BP then? I know, there shouldn't be any in most programs, but sometimes it can be useful, e.g. for efficiency. But it's ok for me if it's only enabled with {$X+}, see below. Peter Gerwinski wrote: > 2) In GPC strings, the schema discriminant "Capacity" is accessible > as a "record field" of the string. Is this okay by ISO 10206, > and should it be done for other schemata this way, too? And how to > tread the "length" field of a string? ISO 10206 6.4.3.3 does not > say anything about that. I could imagine the string schema type to > be something similar to > > Type > String ( Capacity: Integer ) = record > length: Integer; > String: packed array [ 1..Capacity ] of Char; > end (* String *); > > except that the "String" field is automatically dereferenced. Oh - I thought a string was like this already. (My previous mails were based on this assumption.) I think I read this somewhere, but don't remember where. But, a *packed* array? If I remember correctly, it's not possible to get an address of a component of a packed record/array (because they could possibly not start on a byte boundary) (but when trying it, I encountered some problems, see below). If this is so (and won't be changed so that it is possible to get an address of those components that actually start on a byte boundary), I'd vote for an un-packed array here. BTW: Is there any advantage in packing here? AFAICS (at least with Linux), an un-packed array of char is exactly as big as a packed one. Is this not always so? > It's "1..Capacity + 1". (Increasing the index by one adds one char.) > > +1 to allow for a trailing zero (or zero's in case of Unicode...). Does this mean strings will always have an additional trailing #0? Do the string routines currently support this (i.e. automatically add a #0 at the end; but they should not recognize #0 as a terminator, but only rely on the length field)? That would be good, because it simplifies converting a string into a CString a lot (just "CString(@s[1])", right?). > What about the following: > > * Default mode (and Extended Pascal mode): The length field cannot > be accessed (except with "length ( MyStr )".) > > * With extended syntax (*$X+*): The length field can be read- and > write-accessed. > > Okay like that? Or perhaps better to have it in default mode, too, > and to switch it OFF in Extended Pascal mode? I think it's best as > above because you should assign a new length to a string only if you > know exactly what you are doing. Sounds good! {$X} is a local switch, isn't it (so one can turn it on and off around code that needs it, and be safe from accidents elsewhere). It would be even better than BP (where accidental writes to s[0] are not even detected by range checking). :-) BTW: Should the field be called "length" like the function length? It might give conflicts with "with" statements ("with" works with schemata, doesn't it?) as in: with dest_str do begin length:=length(src_str); ... end; Perhaps something like str_length or such? > (* By the way: Good news for all friends of schemata! They might be > finished (except, of course, bugs) this week ... *) What? The bugs will not be finished? What an omission! ;-) As I said above, I had some problems with the new packed arrays. I tried the following: program t; var q:packed array [1..10] of boolean; y:^boolean; begin y:=@q[3] end. and it compiled (though I think it shouldn't), giving quite a strange result in y. Then I did: program t; var q:packed array [1..10] of boolean; y:^boolean; i:integer; begin for i:=1 to 10 do y:=@q[i] end. gpc said "invalid lvalue in unary &". Though this shoudln't compile, this error message seems strange to me. I'd have expected "Attempt to take address of bit-field structure member", as with packed records. Next I tried: program t; var q:packed array [1..10] of boolean; y:^boolean; i:integer; begin for i:=1 to 10 do y:=@(q[i]) end. The result was: "parse error before '('" and some more error messages. (The same with an un-packed array here.) Should the "()" be allowed here (though not required)? FWIW, TP5.5 doesn't allow them, BP7.0 does... -- 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

stdin/stdout
by andi.tio＠hit.handshake.de 01 May '97

01 May '97

Hello, can you please explain me how to use the stdin/stdout with gpc? The compiler does not seem to know these. I tried to declare some functions from libc, but it didn't work, too. Here's my code: ---------------------- program passtrough; function fopen(name:pChar; mode:integer):integer; asmname 'open'; function fclose(handle:integer):integer; asmname 'close'; function fread(handle:integer; VAR Buffer; length:integer):integer; asmname 'read'; function fwrite(handle:integer; VAR Buffer; length:integer):integer; asmname 'write'; CONST O_RDONLY = 00; O_WRONLY = 01; O_RDWR = 02; O_CREAT = 0100; O_EXCL = 0200; O_NOCTTY = 0400; O_TRUNC = 01000; O_APPEND = 02000; O_NONBLOCK = 04000; O_NDELAY = O_NONBLOCK; O_SYNC = 010000; var fin,fout:integer; buffer:array[1..1024] of byte; bytesread:integer; begin fin := fopen('/dev/stdin',O_RDONLY); fout:= fopen('/dev/stdout',O_WRONLY); repeat bytesread:=fread(fin,buffer,1024); if bytesread=-1 then begin writeln('read error'); Halt; end; if fwrite(fout,buffer,bytesread)=-1 then begin writeln('write error'); Halt; end; until bytesread<>1024; fclose(fin); fclose(fout); end. ---------------------- It *does* work when stdin/stdout are connected to the terminal, but when using pipes it seems not to work. Any suggestions? Bye Andreas

1 0

Re^3: Legal Change in GPC ?
by Peter Gerwinski 30 Apr '97

30 Apr '97

According to Christian Wendt: > :-) I do the work and get common to the RTS C source (which is very vell > readable!) - and then learn all the work has been done... Oh - sorry! Since an improved BPcompat package for DOS (DJGPP) will be released soon, what about facing Linux instead? Sven's BGI2GRX (Graph) Unit runs under Linux, but we have no CRT yet ... > PG>available in the `contrib' subdirectory of the GPC distribution. > BPCompat.pas is in my contrib subdirectory... but only "highlevel" > functions... The same stuff as in Borland's CRT, isn't it? > not "impossible"- you only got to reinvent the wheel and write to > $b80000... _big_ loss in portability & comfort (no easy to call writeln. Nevertheless this will remain my preferred method in BO5. The fastest thing you can imagine on the DOS platform. > BTW - is there a way to make a procedure to have a variable count of > parameters? (as writeln) - e.g. would it be possible to define to "C" > printf procedure within pascal ?) Yes and no: You can define a "Procedure Foo ( a, b: Integer; ... );" with a triple dot indicating a variable number of subsequent arguments, but I have not yet found out how to access them ... > But i think that even there it would be quite more comfortable to use > Textcolor instead of write(chr(27)+'[5;33m'); or such... Of course. But a CRT Unit could use these sequences to access the terminal in a portable way. > exactly what I had in mind... don't kill it from the alphas :-) Don't worry. If things develop as I hope, we will enter beta stage soon ... 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

problem with gpclib.a (alpha-version)...
by A.ECKLEDER＠CHATEAU.cl.sub.de 30 Apr '97

30 Apr '97

A.Eckleder(a)chateau.cl.sub.de / oh no,some e-mail ... by ME!!! To: GPC(a)HUT.FI (Gpc) ---------------------------------------------------------------------- ...i've got some problem with the library file of the actual (?!?) alphaversion of gnu-pascal... obviousely there's some problem in string-management (gpc2.0 libs do well) here's some sample code: type normstr=string[255]; {also tested with different string lengths} function strng(z:real):normStr; {convert number to string} var s:normstr; k:byte; neg:boolean; begin k:=0; while (z<>int(z)) and (k<5) do begin z:=z*10; inc (k); end; s:='';if z<0 then neg:=true else neg:=false; z:=int(abs(z)); if z=0 then s:='0'; while z>0 do begin s:=chr(trunc(z-int(z/10)*10)+48)+s; z:=int(z/10); end; if k>0 then s:=copy(s,1,length(s)-k)+'.'+copy(s,length(s)-k+1,k); if neg then s:='-'+s; strng:=s; end; as far as i could analyse the problem,the error occurs within the s:=chr(trunc(z-int(z/10)*10)+48)+s; expression. i know that this is not very optimized code,but it normally works fine though. the other problem i realized with this alpha-version is that i couldn't manage to use the inline assembler. i only only got a message telling me function asm() not beeing existent. because of this strong behavior i use the gpc2.0 compiler with the alpha- libraries...perhaps THIS is the reason why the function above doesn't work, but i am not quite sure about that... andy /------------------- A.ECKLEDER(a)CHATEAU.CL.SUB.DE --------------------\ Who is 'General Failure' - And why is he reading my harddisk ? \------------------ Andreas Eckleder@2:2480/816.32 -------------------/ ## CrossPoint v3.1 ##

1 0

Re: What is standard, and what isn't?
by Berend de Boer 30 Apr '97

30 Apr '97

Peter Gerwinski wrote: >Not too difficult: Integer arrays can be treated by a simple byte >compare; for string arrays the compiler must generate a loop. I thought that was a lot of work, but it seems I was wrong :-) >> Certainly: see the examples in 6.8.4 > >Thanks a lot! I didn't find that. Why wasn't there a single word >about >this in 6.4.7, 6.4.8??? No idea. Just like a lot of other topics treatment is fairly sparse. We need to have everything in one place. Maybe I should write an Extended Pascal programmers book :-) >What about the following: > > * Default mode (and Extended Pascal mode): The length field cannot > be accessed (except with "length ( MyStr )".) > > * With extended syntax (*$X+*): The length field can be read- and > write-accessed. I don't care, because I don't see the need for accessing the length field directory, as long as it is not available in Extended Pascal mode :-) Groetjes, Berend.

1 0

Re: Short strings (Was: Modifying string length?)
by Peter Gerwinski 30 Apr '97

30 Apr '97

According to Stephen Lindholm: > [`ShortStr' or `ShortString'?] > How about supporting both? Since PEP and Delphi agree that this is called `ShortString', I conclude that we should use that, too. However it will take some time until it will be implemented: All string types must be compatible with each other in assignments, comparisions, etc., and all string routines will have to accept all sorts of strings. (Well ... at least some of them will accept all sorts; others might be okay to support EP's long strings only.) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer Reply e-mail to "uni-essen" http://home.pages.de/~peter.gerwinski/ [970201] instead of "NO-SPAM-PLEASE". maintainer GNU Pascal [970412] kampi.hut.fi/gpc Sorry for the inconvenience. http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: What is standard, and what isn't?
by Peter Gerwinski 30 Apr '97

30 Apr '97

According to Berend de Boer: > If you want something 'difficult' to do , implement integer and string > value arrays :-) Not too difficult: Integer arrays can be treated by a simple byte compare; for string arrays the compiler must generate a loop. This can be done for records, too: The compiler can do a loop through the fields of the record. (User programs cannot do that. :-P) > Certainly: see the examples in 6.8.4 Thanks a lot! I didn't find that. Why wasn't there a single word about this in 6.4.7, 6.4.8??? > I think one implements it as: > > Type > String ( Capacity: Integer ) = record > length: Integer; > String: packed array [ 1..Capacity+SizeOf(Char) ] of Char; > end (* String *); It's "1..Capacity + 1". (Increasing the index by one adds one char.) (And it's still an exception since you write "MyStr [ i ]", not "MyStr.String [ i ]".) > However length is not specified in the standard, so it should not be > accessible with Extended Pascal. You can always use length(MyStr) to > achieve the same functionality. What about the following: * Default mode (and Extended Pascal mode): The length field cannot be accessed (except with "length ( MyStr )".) * With extended syntax (*$X+*): The length field can be read- and write-accessed. Okay like that? Or perhaps better to have it in default mode, too, and to switch it OFF in Extended Pascal mode? I think it's best as above because you should assign a new length to a string only if you know exactly what you are doing. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Modifying string length?
by Peter Gerwinski 30 Apr '97

30 Apr '97

According to Frank Heckenbach: > > Hmmm... well, I could not see the effect. I wrote the following test program: > [...] > I compiled it with "-O3 -S". The resulting code contained two calls to > _memcpy. [...] Ah - I was wrong, sorry. The string addition is optimized, but it is done on a temporary variable, and the assignment to that guy is *not* optimized. Maybe this can be changed ... I will have a look at that. (But not now.) (* By the way: Good news for all friends of schemata! They might be finished (except, of course, bugs) this week ... *) 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Short strings (Was: Modifying string length?)
by The African Chief 30 Apr '97

30 Apr '97

On Wed, 30 Apr 1997 00:41:07 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to The African Chief: >> According to Frank Heckenbach: >> >255 chars max length are sometimes not enough. >> But you can use normal GPC strings for that. > >Just my point: For applications where you need looooong strings, GPC's ><=2GB strings with 8 bytes of overhead are perfect. In those cases >where you must save space, 255 characters are fine - and they are >compatible to UCSD and Borland Pascal. > >Should it be `ShortString' or `ShortStr'? In analogy to `LongInt' >instead of `LongInteger' I would vote for `ShortStr'; OTOH, Prospero's >Extended Pascal compiler (PEP) has `ShortString' for this ... Delphi also has "ShortString" - so perhaps we should use that. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: What is standard, and what isn't?
by Berend de Boer 30 Apr '97

30 Apr '97

Peter Gerwinski wrote: >1) Is the comparision with `=' or `<>' of structured variables okay in > ISO Pascal? ISO 10206 6.8.3.5 only says that the types to be compared > must be compatible. No, see the table in 6.8.3.5. And I see quite some problems in implementing this correctly. A simple byte compare won't do except in the most easiest of cases. If you want something 'difficult' to do , implement integer and string value arrays :-) >2) In GPC strings, the schema discriminant "Capacity" is accessible > as a "record field" of the string. Is this okay by ISO 10206, > and should it be done for other schemata this way, too? Certainly: see the examples in 6.8.4 And how >to > tread the "length" field of a string? ISO 10206 6.4.3.3 does not > say anything about that. I could imagine the string schema type >to > be something similar to > > Type > String ( Capacity: Integer ) = record > length: Integer; > String: packed array [ 1..Capacity ] of Char; > end (* String *); > > except that the "String" field is automatically dereferenced. I think one implements it as: Type String ( Capacity: Integer ) = record length: Integer; String: packed array [ 1..Capacity+SizeOf(Char) ] of Char; end (* String *); +1 to allow for a trailing zero (or zero's in case of Unicode...). However length is not specified in the standard, so it should not be accessible with Extended Pascal. You can always use length(MyStr) to achieve the same functionality. Groetjes, Berend.

1 0

Re: Short strings (Was: Modifying string length?)
by Berend de Boer 30 Apr '97

30 Apr '97

You wrote: >Should it be `ShortString' or `ShortStr'? In analogy to `LongInt' Borland uses ShortString in Delphi so I go for ShortString. Groetjes, Berend.

1 0

Re: Modifying string length?
by Frank Heckenbach 30 Apr '97

30 Apr '97

> I would say: GPC *does* optimize this. Just type `gpc -O -S foo.pas' > and look at `foo.s' ... Hmmm... well, I could not see the effect. I wrote the following test program: program x; var s:string[10000]; begin s:=''; s:=s+'a' end. I compiled it with "-O3 -S". The resulting code contained two calls to _memcpy. Another test program that appended characters in a loop obviously ran in O(n^2). Am I missing something? -- 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: exit; ????
by Peter Gerwinski 29 Apr '97

29 Apr '97

According to skye: > > Is Exit not included in GPC? i.e. > [...] > I tried using return; and that works. GPC 2.0 only has `return'; newer alpha versions also have `exit'. > I posted this question to the comp.lang.pascal NG and had someone from > Borland tell me that Exit should do the trick (I didn't say I wasn't using > TP tho). :-) > Is exit a Borland thing? It's an UCSD extension. Borland Pascal is based a lot on UCSD Pascal (Units, Strings, Exit, ...). 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Modifying string length?
by Peter Gerwinski 29 Apr '97

29 Apr '97

According to Frank Heckenbach: > > > > No. They are exceptions in yet another way because they have the > > implicit read-only "length" field. > > That's what I meant. If length was made accessible in a normal way, it > would not be an exception. Being an array schema, the presence of the implicit "length" field would make the string an exception. Being a record schema, the implicit dereference of the "string" field when indexing the string makes it an exception. No way out. (However see my other mail.) 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Short strings (Was: Modifying string length?)
by Peter Gerwinski 29 Apr '97

29 Apr '97

According to The African Chief: > According to Frank Heckenbach: > >255 chars max length are sometimes not enough. > But you can use normal GPC strings for that. Just my point: For applications where you need looooong strings, GPC's <=2GB strings with 8 bytes of overhead are perfect. In those cases where you must save space, 255 characters are fine - and they are compatible to UCSD and Borland Pascal. Should it be `ShortString' or `ShortStr'? In analogy to `LongInt' instead of `LongInteger' I would vote for `ShortStr'; OTOH, Prospero's Extended Pascal compiler (PEP) has `ShortString' for this ... 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Modifying string length?
by The African Chief 29 Apr '97

29 Apr '97

On Tue, 29 Apr 1997 12:53:53 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: [...] >> It would not be too difficult to make "MyStr.length" and "MyStr.String" >> accessible "record fields" of strings. Would it be desireable? > >Yes! (At least length; the String part is accessible anyway with s[n].) > >> I am >> not sure how this fits into the standard ... > >I'm not, either. If it conflicts, it should be disabled with >"--extended-pascal", I suppose. It should be disabled, with "-borlland-pascal" as well. >> Another thing *is* planned: A new data type `ShortString' (or >> `ShortStr'?) which will be the UCSD/Borland version of Strings. In many >> contexts, they are better than Extended Pascal string schemata because >> they have only 1 byte overhead instead of 8. (But this will be a lot >> of work. Anybody interested to help here???) > >What about another type with a 2 byte length field (2 instead of 8 bytes >overhead)? Will this be BP compatible? >255 chars max length are sometimes not enough. But you can use normal GPC strings for that. >BTW: I heard >Delphi has some kind of long strings. Anyone knows what they are? Only available with 32-bit versions of Delphi. Sort of dynamically allocated strings. Delphi does all the background work itself (allocating, freeing, sizing, resizing, etc). I think they can be up to 2GB in size. Need to be used with care, because all sorts of things can go wrong if you treat them like normal strings. "Almost" compatible with pChars. You can do something like "PChar (MyLongString)" to pass a long string as a parameter to a function that requires a pChar parameter. When used as parameters or function results in a DLL, all programs that use that DLL must use Delphi's memory manager DLL as well. Personally, I wouldn't touch them with a barge pole. I would rather use a pChar, if that is what I want, or a normal string, if that is what I want - and I prefer to allocate and free memory for data structures myself. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: Modifying string length?
by Frank Heckenbach 29 Apr '97

29 Apr '97

> I would say: GPC *does* optimize this. Just type `gpc -O -S foo.pas' > and look at `foo.s' ... Fine! I'll take a look at it. > It would not be too difficult to make "MyStr.length" and "MyStr.String" > accessible "record fields" of strings. Would it be desireable? Yes! (At least length; the String part is accessible anyway with s[n].) > I am > not sure how this fits into the standard ... I'm not, either. If it conflicts, it should be disabled with "--extended-pascal", I suppose. > Another thing *is* planned: A new data type `ShortString' (or > `ShortStr'?) which will be the UCSD/Borland version of Strings. In many > contexts, they are better than Extended Pascal string schemata because > they have only 1 byte overhead instead of 8. (But this will be a lot > of work. Anybody interested to help here???) What about another type with a 2 byte length field (2 instead of 8 bytes overhead)? 255 chars max length are sometimes not enough. BTW: I heard Delphi has some kind of long strings. Anyone knows what they are? > > (Are you planning > > to make strings regular schema types then -- regular except for the extended > > syntax that allows s[n]?) > > No. They are exceptions in yet another way because they have the > implicit read-only "length" field. That's what I meant. If length was made accessible in a normal way, it would not be an exception. -- Frank Heckenbach, Erlangen, Germany heckenb[No_Spam! Remove this to reply.](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: Modifying string length?
by Peter Gerwinski 28 Apr '97

28 Apr '97

According to Frank Heckenbach: > > Well, the problem is, I said "efficiently". > I don't assume, gpc would optimize statements like > s:=s+'a' > where s is a (possibly quite long) string, so I'd have O(n) where actually > O(1) is possible. I would say: GPC *does* optimize this. Just type `gpc -O -S foo.pas' and look at `foo.s' ... > E.g. the examples from the documentation about converting > CStrings to Pascal strings append char by char in a loop -- O(n^2) instead > of O(n). I don't think that should be left as it is. You mean the routines in the FAQ? I think they are O(n) because "S:= S + Src^" is inlined and optimized. But of course, feel free to improve those routines and send the result to Jan-Jaap ... ;-) > I'd have to do it like this if there's no other way... > But shouldn't it be possible to access the fields of the "string record" in > a direct way? Perhaps in the course of the schema project? It would not be too difficult to make "MyStr.length" and "MyStr.String" accessible "record fields" of strings. Would it be desireable? I am not sure how this fits into the standard ... Another thing *is* planned: A new data type `ShortString' (or `ShortStr'?) which will be the UCSD/Borland version of Strings. In many contexts, they are better than Extended Pascal string schemata because they have only 1 byte overhead instead of 8. (But this will be a lot of work. Anybody interested to help here???) > (Are you planning > to make strings regular schema types then -- regular except for the extended > syntax that allows s[n]?) No. They are exceptions in yet another way because they have the implicit read-only "length" field. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Peter Gerwinski wrote:
by Frank Heckenbach 28 Apr '97

28 Apr '97

> > Is there a way to change a string's length directly? > > AFAIK, there isn't. Use the `SubStr' function (like BP's `copy' function) > to shorten a string, and the `+' operator to make it longer. Well, the problem is, I said "efficiently". I don't assume, gpc would optimize statements like s:=s+'a' where s is a (possibly quite long) string, so I'd have O(n) where actually O(1) is possible. E.g. the examples from the documentation about converting CStrings to Pascal strings append char by char in a loop -- O(n^2) instead of O(n). I don't think that should be left as it is. > And of course you can take a pointer to the string, cast it to a pointer > to a record the fields of which you can manipulate like you wish ... I'd have to do it like this if there's no other way... But shouldn't it be possible to access the fields of the "string record" in a direct way? Perhaps in the course of the schema project? (Are you planning to make strings regular schema types then -- regular except for the extended syntax that allows s[n]?) -- Frank Heckenbach, Erlangen, Germany heckenb[No_Spam! Remove this to reply.](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: CStrings
by Frank Heckenbach 28 Apr '97

28 Apr '97

Peter Gerwinski wrote: > I encountered some problems with Procedures accepting `CString' > parameters. When passing a string constant to such a parameter, GPC > does *not* automatically add a "chr ( 0 )" terminator. > > Should it do? And if so, in which cases? We always can explicitly write > "foo ( 'bar'#0 );" instead of just "foo ( 'bar' );", so I tend to let > things like they are ... I think it should automatically add a #0 terminator. After all, a "CString" without terminator is somewhat undefined. In which cases? I think always when a string constant is given where a "CString" value is expected, whether for a parameter, or a variable initializer. E.g. the following should work as expected: var numbers:array[1..3] of cstring value (1:'one';2:'two';3:'three'); or in BP syntax: const numbers:array[1..3] of pchar=('one','two','three'); Many of my programs rely on this. -- Frank Heckenbach, Erlangen, Germany heckenb[No_Spam! Remove this to reply.](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: Legal Change in GPC ?
by Peter Gerwinski 28 Apr '97

28 Apr '97

According to Christian Wendt: > > I wondered how to implement the ability to change colours and write text > to Standard output - but I think it's nearly impossible to do this within > a Unit - the C - Textcolor doesn't work with the fprintf function that is > used in the RTS... Nevertheless I did this. :-) Please have a look at the BPcompat package, available in the `contrib' subdirectory of the GPC distribution. > I wondered wether it would be legal (in sense of > portability and compability...) to change the RTS : Textcolor works if you > check wether the file passed to writeln is Stdout - when it is you use > cprintf (or putch instead of fwrite). You are right that this is a problem we must think about. In this case I think it increases portability and compatibility to do the changes because otherwise it is impossible to get colors under DOS whereas you can have them with Linux or any other system which provides colors as terminal escape sequences, e.g. according to ANSI. > The question is - would it be legal to do such - you could put in a > variable (smth like "GPC_ConsoleOutput") to switch in on/off ? In the BPcompat package or in newer Alpha releases of GPC, this variable exists and is called `p_directvideo', available as `DirectVideo' if you do `uses CRT'. If it is `true', `writeln' is performed through `cprintf', otherwise through `printf'. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: CStrings
by The African Chief 28 Apr '97

28 Apr '97

On Sun, 27 Apr 1997 17:34:47 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >Hello, > >I encountered some problems with Procedures accepting `CString' >parameters. When passing a string constant to such a parameter, GPC >does *not* automatically add a "chr ( 0 )" terminator. > >Should it do? I personally think so. >And if so, in which cases? "In all cases", I would venture to say. > We always can explicitly write "foo ( 'bar'#0 );" instead >of just "foo ( 'bar' );", so I tend to let things like they are ... The string constant parameter is something that thinks it is (or is pretending to be) a CString. Since CStrings end with a Chr(0), it is probably best to make the string constant do so automatically - otherwise, its pretensions would be found out very quickly. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: CStrings
by Berend de Boer 28 Apr '97

28 Apr '97

You wrote: >I encountered some problems with Procedures accepting `CString' >parameters. When passing a string constant to such a parameter, GPC >does *not* automatically add a "chr ( 0 )" terminator. I think it should. Much less confusing, probably more portable and in Extended Pascal #0 is not recognized, so means a few characters more typing pain. Another solution, whith less performance impact would be to always add a chr(0) to a string constant at compile time. I think I favor this approach. The length returned should be the length minus chr(0) but the chr(0) should be there. Groetjes, Berend.

1 0

Legal Change in GPC ?
by C.WENDT＠CHATEAU.cl.sub.de 28 Apr '97

28 Apr '97

Am 25.04.97 konnte ich meine Finger einfach nicht von der Tastatur fernhalten... Folgendes kam dabei heraus: Hallo! I wondered how to implement the ability to change colours and write text to Standard output - but I think it's nearly impossible to do this within a Unit - the C - Textcolor doesn't work with the fprintf function that is used in the RTS... I wondered wether it would be legal (in sense of portability and compability...) to change the RTS : Textcolor works if you check wether the file passed to writeln is Stdout - when it is you use cprintf (or putch instead of fwrite). The question is - would it be legal to do such - you could put in a variable (smth like "GPC_ConsoleOutput") to switch in on/off ? Chris --- HomeBox : Chateau - 08677 911940(V.34) 911941(ISDN) ## CrossPoint v3.11 ##

1 0

passing pointers, GPC documentation
by Peter Gerwinski 27 Apr '97

27 Apr '97

According to skye: > > Yes, I can get that to work but what still fails is when gBuffer is > allocated using new(): > [...] > ScreenBlit( gBuffer); (* crashes in the movedata() from the std C lib *) Again: How did you declare the "ScreenBlit" procedure? > Now I'm not too sure how memory allocation works under pascal. Is this > right? I don't have many examples to got from and they all work something > like this. would this be the same as this in C: > > char* gBuffer; > gBuffer = malloc(320*200); > free(gBuffer); Yes. > now I haven't seen GetMem before. The examples I'm using just use the > method i've shown above. Does GetMem work like malloc() where I can specify > the amount at runtime? (this would be nice). Yes. `GetMem' is a Borland Pascal extension: GetMem ( gBuffer, 320 * 200 ); FreeMem ( gBuffer, 320 * 200 ); GPC also allows the following: gBuffer:= GetMem ( 320 * 200 ); FreeMem ( gBuffer ); (* 2. parameter is optional in GPC *) > Also, isn't there a limit to the amount of static variable memory I can use > (DS)? No. > I don't want to have to fidle with my compiler options to increase > it. If I have a static array that is 64k there is potental for probles way > down the road, esp. if I have other large static structres. Feel free to allocate static structures of 1MB or above. This is one reason why I am using GPC rather than BP for scientific programs. (-: > Sorry about the basic Pascal questions. It is strange switching from C/C++ > to Pascal without documentation. I keep trying to do something one way and > find out after much frustration that is done another in Pascal. I have only > a few Pascal DOCS I have found online and they all use TP. Are there any > using GPC? AFAIK, the only existing GPC documentation is our info documentation and the GPC FAQ. You can find both in your GPC distribution, or online at http://home.pages.de/~GNU-Pascal/gpc-doc.html http://home.pages.de/~GNU-Pascal/gpc-faq.html If anybody wants to help to create more documentation, I suggest the following: Collect all this information from this list, e.g. the `GetMem' stuff above, put it into a reasonable structure, and add it to the GNU Texinfo documentation. If you have any questions, be sure that I will help you. Like this, the reference will be made available as on-line help, e.g. with Ctrl+F1 when using the RHIDE. I am starting to do this *now* by writing something about Integer types. It is appended below, so you have an example what I am speaking of and would like to recieve. If you have more ideas, e.g. to write something about `writeln', just do it and post it here! 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125] 8< --------------------------------------------------------------------------- @node Integer @subsection Integer @cindex Integer types GNU Pascal supports the following Integer types: @table @samp @item ByteInt signed 8-bit integer type, @samp{-128..128} @item Byte unsigned 8-bit integer type, @samp{0..255} @item ShortInt signed 16-bit integer type, @samp{-32768..32767} @item ShortWord unsigned 16-bit integer type, @samp{0..65535} @item Integer signed 32-bit integer type, @samp{-2147483648..2147483647} @item Word unsigned 32-bit integer type, @samp{0..4294967295} @item LongInt signed 64-bit integer type, @samp{-9223372036854775808..9223372036854775807} @item LongWord unsigned 64-bit integer type, @samp{0..18446744073709551615} @end table ISO Pascal defines only @samp{Integer}; the other types are GNU extensions. Some of these types (@samp{Byte}, @samp{ShortInt}, @samp{Word}, and @samp{LongInt}) are available in Borland Pascal, too, but have a different size there. For sake of compatibility to Borland Pascal, @samp{LongInt} can also be called @samp{Comp}. On the i386 processor family, operations with @samp{Integer} usually work faster than operations with shorter integer types like @samp{ShortInt} or @samp{ByteInt}. @strong{Known bug:} At the moment, GPC's run time library is not able to @samp{write} or @samp{writeln} integer types longer than @samp{Integer}. @c ---------------------------------------------------------------------------- @node LongInt @subsection LongInt @samp{LongInt} is GPC's signed 64-bit integer type, @samp{-9223372036854775808..9223372036854775807}. For sake of compatibility to Borland Pascal, @samp{LongInt} can also be called @samp{Comp}. @xref{Integer} @xref{LongWord} @xref{Comp} @c ---------------------------------------------------------------------------- @node LongWord @subsection LongWord @samp{ByteInt} is GPC's unsigned unsigned 64-bit integer type, @samp{0..18446744073709551615}. @xref{Integer} @xref{LongInt} @c ============================================================================

1 0

Re: Modifying string length?
by Peter Gerwinski 27 Apr '97

27 Apr '97

According to Frank Heckenbach: > > Is there a way to change a string's length directly? AFAIK, there isn't. Use the `SubStr' function (like BP's `copy' function) to shorten a string, and the `+' operator to make it longer. And of course you can take a pointer to the string, cast it to a pointer to a record the fields of which you can manipulate like you wish ... > BTW: Are the TP string routines (e.g. Insert, Delete) already ported to gpc? The African Chief is working on this. (-: It will probably be released soon. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: New Alpha: EMX run time library broken?
by Kevin A. Foss 27 Apr '97

27 Apr '97

On Wed, 23 Apr 1997 21:47:37 +0200 (MET DST), Peter Gerwinski wrote: >I was reported that the EMX run time library of the latest alpha GPC >(gpc-970420) is broken: Not even `hello.pas' can be linked. > >Since I cannot reproduce the error on my own system (I can link even >more complicated EMX programs here ... :-) I ask whether somebody else >has observed the same problem. Perhaps there is a bug which only shows >up in some configurations ... Well I was the one who reported the above problem to Peter and after messing around for 5 days trying to apply the patches, compile it myself, using gdb to trace the source, I have found the problem: I'm a moron. I found I had an older version of the gpc executables in my path before the newer versions, but I was putting the library in the correct place. [For various reasons, I don't like putting anything except the EMX distribution in the \EMX directory tree.] So when I tried to compile hello.pas, the old 2.0 executables were trying to use the new runtime library from the latest alpha and things didn't go well. So, my apologies to Peter and to anyone else who might have wasted time looking for a fix to this problem. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

CStrings
by Peter Gerwinski 27 Apr '97

27 Apr '97

Hello, I encountered some problems with Procedures accepting `CString' parameters. When passing a string constant to such a parameter, GPC does *not* automatically add a "chr ( 0 )" terminator. Should it do? And if so, in which cases? We always can explicitly write "foo ( 'bar'#0 );" instead of just "foo ( 'bar' );", so I tend to let things like they are ... 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: errors when passing pointers from a unit
by Peter Gerwinski 27 Apr '97

27 Apr '97

According to skye: > > var > gBuffer"^mode13VideoBuffer; You mean: gBuffer: ^mode13VideoBuffer;-). > [...] > All my graphic functions draw to this buffer. To get it to the screen I > have a procedre that calls an external C function: > procedure gUpdate; > begin > screenblit( gBuffer); > end; How is this C function declared in the Pascal program? As "Procedure ScreenBlit ( gBuffer: Pointer ); C;"? Then it should work. > [...] > This only crashes when I pass it a pointer from my unit. I can do the exact > same allocation from the main program file and it will work OK. This I don't understand. You mean that you are using a statically allocated video buffer in the Pascal program and passing a pointer to it to the C program? The following should work: Program Whatever; Type mode13VideoBuffer = array [ 1 .. 320 * 200 ] of Byte; mode13VideoBufferPtr = ^mode13VideoBuffer; Var gBuffer: mode13VideoBuffer; (* NOT a pointer to it *) Procedure ScreenBlit ( Buffer: mode13VideoBufferPtr ); C; begin ScreenBlit ( @gBuffer ); end. > Am I getting confused on how pointers work in C and how they work in Pascal > (I thought that they were pretty much the same except for type checking Yes, they are. > and "true" dynamic allocation)? What's that? What's "false" with `New' and `GetMem'? :-) 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Modifying string length?
by Frank Heckenbach 27 Apr '97

27 Apr '97

Hi everybody! Is there a way to change a string's length directly? "s.length:=..." doesn't work, neither (obviously) "length(s):=...". But I think it's necessary in order to implement some low-level string manipulation routines efficiently. BTW: Are the TP string routines (e.g. Insert, Delete) already ported to gpc? -- Frank Heckenbach, Erlangen, Germany heckenb[No_Spam! Remove this to reply.](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

Combining C and Pascal source. (Was: Const conflict.)
by Peter Gerwinski 26 Apr '97

26 Apr '97

Frank Heckenbach wrote: > > > If I compile it with "gpc foo.pas bar.c", it works fine. But if I do > > > "gpc bar.c foo.pas", it doesn't ("Undefined references" to the C functions). > > [...] > I don't think that's the problem. I tried invocing ld manually, and it worked > whether bar.o was put before or after the Pascal .o's. > [...] > So, probably this has got something to do with the left over .gpc file... 1. I cannot reproduce this error. :-( On my system, "gpc foo.pas bar.c" and "gpc bar.c foo.pas" both work fine - on DJGPP as well as on Linux. This will be hard to fix. 2. I think I have found the problem: :-) The `gpc' driver program assumes that the first input file is a Pascal source when doing `--automake'. I fixed this in `gcc.c'; please retry with the next Alpha GPC. (A diff for `gcc.c' is appended below.) 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125] 8< --------------------------------------------------------------------------- --- gpc-970420/gcc.c Fri Apr 18 12:46:41 1997 +++ gpc/gcc.c Sat Apr 26 10:56:14 1997 @@ -4994,25 +4994,36 @@ obstack_grow (&collect_obstack, "\0", 1); putenv (obstack_finish (&collect_obstack)); #ifdef GPC - /* Substitute the basename of the first input file for %b in - link_command_spec. */ + /* Substitute the basename of the first Pascal + * input file for %b in link_command_spec. + */ + i = 0; + while (i < n_infiles + && infiles[i].language + && strcmp (infiles[i].language, "p") != 0 + && strcmp (infiles[i].language, "pas") != 0) + {fprintf (stderr, "%d\n", i); i++;} + if (i < n_infiles) + { + input_basename = infiles[i].name; + for (p = input_basename; *p; p++) + if (*p == '/') + input_basename = p + 1; - input_basename = infiles[0].name; - for (p = input_basename; *p; p++) - if (*p == '/') - input_basename = p + 1; + /* Find a suffix starting with the last period, + * and set basename_length to exclude that suffix. + */ + basename_length = strlen (input_basename); + p = input_basename + basename_length; + while (p != input_basename && *p != '.') + p--; + if (*p == '.' && p != input_basename) + basename_length = p - input_basename; - /* Find a suffix starting with the last period, - and set basename_length to exclude that suffix. */ - basename_length = strlen (input_basename); - p = input_basename + basename_length; - while (p != input_basename && *p != '.') --p; - if (*p == '.' && p != input_basename) - basename_length = p - input_basename; - - explicit_link_files = add_automake_files (explicit_link_files); + explicit_link_files = add_automake_files (explicit_link_files); + } #endif /* GPC*/ value = do_spec (link_command_spec); if (value < 0)

1 0

Re: Const conflict.
by Peter Gerwinski 26 Apr '97

26 Apr '97

According to Jukka Virtanen: > > [Making the parser more clever ...] > > Then it remains the problem how to interpret the following: > > foo_problem : false .. true = false; > > Because that can be interpreted either as an initialized > or uninitialized subrange. If I were a Pascal compiler, I would read this as an initialized variable. OTOH, a true Extended Pascal compiler *must* read this as a subrange. I think it is save to exclude comparisions with `=' from the expressions valid for the upper bound. The reason for allowing expressions here is to have things like `+', `*', parentheses, etc. in the upper bound; subranges of the Boolean type are exotic enougth that we can immolate them. (Hmm ... somebody might need something like Var Foo: 1 .. 4 + ord ( bar = 3 ) + MyFunc ( A = B ); so I will switch on the `=' again in parentheses and such.) > Extended pascal does require that both bounds of > a subrange can be arbitrary expressions. In GPC (as far > as I recall) only the lower bound can be an expression, > the upper bound needs to be constant, [...] Vice versa. > Anyone who really knows how to hack parsers interested > in this one? I join Juki in asking this question. I think I can fool GPC not to recognize the `=' in upper bound expressions (unless, of course, `--extended-pascal' is on), but I have no idea what to do with the lower bound. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: BP Turbo Vision sources
by Peter Gerwinski 26 Apr '97

26 Apr '97

According to Jan-Jaap van der Heijden: > > I collected this discussion from comp.os.msdos.programmer.turbvision. > Somebody claims to have gotten permission from Borland to release the BP > Tvision sources to the public "as long as they are not sold". GNU Pascal > is definately the "not for money" category so this may be interesting to > us. Not so definitely. The GPL allows to sell copies of GPC as long as the clients get all rights the vendor had. > Having Turbo Vision available would make it much easier to write > attractive applications, at least for the djgpp/dos port of GPC. Really. We must not distribute Turbo Vision "as part of GPC" because this would restrict distribution of GPC, but it can be in the "contrib" subdirectory. > But I do think we should wait and see what happens next.... I agree. Some official notes from Borland would be good. (The telephone call somebody in a NewsGroup spoke about would not be accepted as a proof in a lawsuit.) (* And GPC cannot compile Turbo Vision anyway at the moment. *) 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: BP style objects: errors.
by Peter Gerwinski 26 Apr '97

26 Apr '97

According to Jan-Jaap van der Heijden: > > 1) References to an incomplete type are not accepted. [...] That's a new bug. I will have a look at it. > 2) Something simular appens in the implementation part: > > [...] > > TErrorProc = procedure(var S: TStream); GPC does not (yet;) have BP's "procedural variables". It has *pointers* to procedures instead. The above can be translated to TErrorProc = ^Procedure ( ????????? TStream ); - ah, sorry! `Var' parameters don't work in this context! Bug!!! Okay, I will see how difficult it is to implement BP's procedural types ... > 3) Obviously, `self' is treated different too... This I don't understand. > All of this with the latest-but-one alpha release, in BP mode with > extended syntax. It should not be necessary to run GPC in BP mode. `--borland-pascal' does not switch ON anything; it only switches OFF the Extended Pascal extensions. And vice versa. I suggest to write all new source for GPC's default mode and to use `--borland-pascal' (or `--extended-pascal' for that matter) just for testing or when worrying about compatibility to Borland (respectively Extended) Pascal. (*$X+, M Extended Syntax is a different thing because it really switches ON some "dangerous" features of GPC. *) > BTW: of course, what I was trying out, was how much trouble it would be to > port TVision to GPC. Seems we have a long way to go.... We will see. (* But anyway I aim to write something *better* ... ;*) > With sufficient thrust, pigs fly just fine. However, this is not > necessarily a good idea. [...] But there may be some people whose programs rely on flying pigs. I am prepared to implement yet another option `--flying-pigs' for such purposes ... 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

errors when passing pointers from a unit
by skye 25 Apr '97

25 Apr '97

I don't realy understand this. I'm new to Pascal tho I've programmed in C for quite some time. I have a unit that dose some _basic_ mode 13h graphics stuff. In it is an off-screen buffer created my allocating a type defined as: type mode13VideoBuffer = array[1..64000] of char; var gBuffer"^mode13VideoBuffer; I have 2 procedures that set up the video mode (by calling some external C functions) and allocate this buffer. procedure InitGraphics; begin {set video mode and other initalization stuff} new(gBuffer); end; procedure TextMode; begin {reset the display and clean up video stuff} dispose(gBuffer); end; All my graphic functions draw to this buffer. To get it to the screen I have a procedre that calls an external C function: procedure gUpdate; begin screenblit( gBuffer); end; It is in this C function that I crash. Here's the screenblit function: //uses libc.a functions void screenblit( unsigned char* buf) { short video = __dpmi_segment_to_descriptor(0xa000); movedata(_my_ds(), (int)buf, video, 0, 320*200); } This only crashes when I pass it a pointer from my unit. I can do the exact same allocation from the main program file and it will work OK. Am I getting confused on how pointers work in C and how they work in Pascal (I thought that they were pretty much the same except for type checking and "true" dynamic allocation)? This how I compile and link: I create a lib from the compiled .o files from my units. I then compile my test program linking in the lib: gpc -g -o gtest.exe gtest.pas -lglib ^^^^ This is my lib NOTE: I can get this system to work in C by replicating the units in .h and .c files and linking the object files on the commanline. HELP? -SC

1 0

BP style objects: errors.
by Jan-Jaap van der Heijden 24 Apr '97

24 Apr '97

Hello, Using gpc to compile (some parts of) Borland's objects unit, I noticed this (so far): 1) References to an incomplete type are not accepted. In the code below, CopyFrom uses a variable S of type TStream, while TStream is not yet finished: type PStream = ^TStream; TStream = object(TObject) Status: Integer; ErrorInfo: Integer; constructor Init; procedure CopyFrom(var S: TStream; Count: Longint); ... BP accepts this, gpc barfs: "type name expected, identifier `Tstream' given" 2) Something simular appens in the implementation part: procedure TStream.Error(Code, Info: Integer); type TErrorProc = procedure(var S: TStream); begin Status := Code; ErrorInfo := Info; if StreamError <> nil then TErrorProc(StreamError)(Self); end; This results in an error: objects.pas: In function `Tstream_Error': objects.pas:141: `object' type definition only allowed at top level objects.pas:141: parse error before `Procedure' objects.pas:142: pointer domain type `Terrorproc' undefined objects.pas:145: undeclared identifier `Terrorproc' (first use this function) objects.pas:145: (Each undeclared identifier is reported only once objects.pas:145: for each function it appears in.) objects.pas:145: parse error before `(' objects.pas:145: missing semicolon objects.pas:145: missing semicolon 3) Obviously, `self' is treated different too... All of this with the latest-but-one alpha release, in BP mode with extended syntax. BTW: of course, what I was trying out, was how much trouble it would be to port TVision to GPC. Seems we have a long way to go.... Greetings, JanJaap -- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

Re: New Alpha
by Peter Gerwinski 24 Apr '97

24 Apr '97

According to Frank Heckenbach: > [...] > However, the following still doesn't work (if it's already/still on the bug > list, please ignore): > > PROGRAM x; > CONST n:1..16=6; {"subrange bounds are not of the same type"} > BEGIN > END. Is this really a bug??? Extended Pascal allows expressions as the upper bound of a subrange. In this case, the expresson "16 = 6" (with the Boolean value "false") is the upper bound - which is indeed not of the same type as the lower bound "1". This is a known shift/reduce conflict in the parser. In principle it should be possible to tell bison to shift it rather than to reduce it - just like with the "dangling else" problem. Since I am a complete beginner with parsers (no theoretical knowledge; my only experience with bison relates to GPC) I would be glad if somebody could help me with this. > {The same with "var ...=...", ok with "var ... value ..."} Strange. On my box, it works with `value'. > Then, a very small problem: > > I have a Pascal program (let's say foo.pas) that uses some units. > [...] > If I compile it with "gpc foo.pas bar.c", it works fine. But if I do > "gpc bar.c foo.pas", it doesn't ("Undefined references" to the C functions). I think that's intended: The GNU linker is a one-pass linker which needs the "lowest" unit in the most right position of the command line. (I think. I don't really know.;-) > In the latter situation also the file foo.gpc is left. That's indeed a bug. Thanks for the report. 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

4 3

Re: Const conflict. Was: Re: New Alpha
by Frank Heckenbach 24 Apr '97

24 Apr '97

Peter Gerwinski wrote: > > {The same with "var ...=...", ok with "var ... value ..."} > > Strange. On my box, it works with `value'. Yes, I meant it's ok with "value". Perhaps I was unclear. > > I have a Pascal program (let's say foo.pas) that uses some units. > > [...] > > If I compile it with "gpc foo.pas bar.c", it works fine. But if I do > > "gpc bar.c foo.pas", it doesn't ("Undefined references" to the C functions). > > I think that's intended: The GNU linker is a one-pass linker which needs > the "lowest" unit in the most right position of the command line. > (I think. I don't really know.;-) I don't think that's the problem. I tried invocing ld manually, and it worked whether bar.o was put before or after the Pascal .o's. However, I noticed that the "automade" unit's .o files were not passed to ld in the latter case: In the first case, gpc issued "ld ... some.o units.o foo.o bar.o ...", in the latter case, it was just "ld ... bar.o foo.o ..." (where foo.o and bar.o were actually temp file names containing the compiled code from foo.pas and bar.c, of course). So, probably this has got something to do with the left over .gpc file... Jakob Heinemann wrote: > > > PROGRAM x; > > > CONST n:1..16=6; {"subrange bounds are not of the same type"} > > > BEGIN > > > END. > > > Is this really a bug??? Extended Pascal allows expressions as the upper > > bound of a subrange. In this case, the expresson "16 = 6" (with the > > Boolean value "false") is the upper bound - which is indeed not of the > > same type as the lower bound "1". Sorry, I didn't see the other possible interpretation when I reported the problem. Actually, BTW, there is a bug in BP - it doesn't even accept the following... ;-) const x:false..(2=3)=false; > I Suppose Frank intended to have a specific value of a subrange as a > constant, but really this is not a good code example, for making good > use of constants in a program you should make an explicit type > declaration, > and though I have not tried it this should work: Thanks for the hint, that's what I'm doing now. It solves the "bug". Phil Nelson wrote: > By forcing the reduce > then the construct "CONST N : false .. 1 = 1 = false;" produces a syntax > error. But, you can still do this by "CONST N : false .. (1 = 1) = false;"; > So I would say that you do want to force the reduce and make equals have to be > parenthesized to get comparison. I thought so, too, but then I realized that this might break some Extended Pascal code: var n:false..1=2; would be valid in EP, but cause an error with the above modification. var n:false..false=false; would declare "n:false..true" uninitialized in EP, but "n:false..false value false" with the modification. While it doesn't seem to do any harm that the variable is initialized, it would make a difference that the range is limited, and a statement like "n:=true" would fail (with some kind of range checking)... Sure, such things are not likely to occur in any real program, but perhaps in some test suites (and if not, they might have to be added to the test suites to claim really 100.00000% compatibility some time)... So, I guess, to remain compatible, the modification can be effective only with "--borland-pascal", or at least not with "--extended-pascal". But I don't know if it's possible to modify the parsing rules depending on switches. If not, I suggest to leave it as it is, and to issue a warning whenever such a thing is encountered, regardless of the switches, since it can be avoided in any case, as was shown, by parentheses or by an explicit type declaration (perhaps the text of the warning should also contain the solutions to avoid confusing people (like me) who encounter it for the first time). -- 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

BP Turbo Vision sources
by Jan-Jaap van der Heijden 24 Apr '97

24 Apr '97

Hello, I collected this discussion from comp.os.msdos.programmer.turbvision. Somebody claims to have gotten permission from Borland to release the BP Tvision sources to the public "as long as they are not sold". GNU Pascal is definately the "not for money" category so this may be interesting to us. Having Turbo Vision available would make it much easier to write attractive applications, at least for the djgpp/dos port of GPC. But I do think we should wait and see what happens next.... Greetings, JanJaap ========================================================================== Subject: TV Pascal sources ? From: marco(a)pool.informatik.rwth-aachen.de (Marco Schmidt) Date: 1997/03/29 Message-Id: <333d55d9.15365994(a)news.rwth-aachen.de> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] Hi, are there any Turbo Vision Pascal sources available as it is the case for C / C++ ? Thanks in advance, Marco -- Marco Schmidt - Student of Computer Science, Aachen, Germany mailto:marco@pool.informatik.rwth-aachen.de http://www.geocities.com/SiliconValley/Lakes/6686 PGP public key available on my web page - key fingerprint : 78 EC A5 87 34 56 F8 10 C2 6D AF A4 16 6C 08 76 ========================================================================= Subject: Re: TV Pascal sources . From: sukud(a)pncl.co.uk (sukud) Date: 1997/04/01 Message-Id: <5hq8mp$81f(a)soap.uunet.pipex.com> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] article <333d55d9.15365994(a)news.rwth-aachen.de>, marco(a)pool.informatik.rwth-aachen.de says... > >Hi, > >are there any Turbo Vision Pascal sources available as it is the case >for C / C++ ? > >Thanks in advance, >Marco >-- >Marco Schmidt - Student of Computer Science, Aachen, Germany >mailto:marco@pool.informatik.rwth-aachen.de >http://www.geocities.com/SiliconValley/Lakes/6686 >PGP public key available on my web page - key fingerprint : >78 EC A5 87 34 56 F8 10 C2 6D AF A4 16 6C 08 76 Yes there are. I think you can get them perhaps through your local Borland branch. But when I was traing to get source code for Delhi, the staff behaind the phone was confused when I sad source code of delhi component and was not able to help me. Having source code can be very usefull. For instance just for look, or for making some private part of objict not private, because I neet it. In my case I wanted to change object Tview and with it all his descendats. I wanted make there somethink like object inspector in Delphi, but more stupid. Petr Soukup sukud(a)pncl.co.uk ========================================================================= Subject: Re: Turbo Vision source code. From: "Wellige" <Wellige(a)itk.de> Date: 1997/01/10 Message-Id: <01bbfef7$a07dd940$bd9562c1(a)itk_ms_wellige.itk.de> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] Miguel Angelo Henley <michael(a)iis.com.br> wrote... > I'm looking for turbo vision source code for turbo pascal. > Where can I find it ? TV source code comes with BP7. As far as I know is the TV Pascal code not free as the C code already is. So I would be suprised if there is a chance to download it. Regards, Tom. -- Tom Wellige wellige(a)itk.de http://www.kst.dit.ie/people/twellige ========================================================================= Subject: TV Pascal Source (was Re: [Q] Need more than integer for TPoint From: sl65r(a)cc.usu.edu (Paul Hepworth) Date: 1997/04/17 Message-Id: <1997Apr17.190452.97084(a)cc.usu.edu> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] > I've already posted a request for source to this ng, but nobody knew > .. though I got some mails of people who'd like to have the source > code themselves. Sorry, nothing found so far. BP7 came with the source code to pascal TV. I think TP6 did as well, but I'm not positive (I gave away my tp6). I have the sources from BP7, but I haven't read whether Borland has given them to the public domain along with the c++ version or not. If they have, I can make the sources available from my web page. Anyone have a .borland.com URL that shows the public domaining of TV? ========================================================================= Subject: Re: TV Pascal Source (was Re: [Q] Need more than integer for TPoint From: "Wellige" <Wellige(a)itk.de> Date: 1997/04/18 Message-Id: <5j75uj$53o(a)news.Dortmund.Germany.EU.net> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] Paul, >BP7 came with the source code to pascal TV. I think TP6 did as well, but >I'm not positive (I gave away my tp6). I have the sources from BP7, but >I haven't read whether Borland has given them to the public domain along >with the c++ version or not. If they have, I can make the sources available >from my web page. Anyone have a .borland.com URL that shows the public >domaining of TV? A few weeks ago I spoke to someone from Borland Germany and he told me that the sources are free as long as they are not sold. It's definatley allowed to publish them e.g. on the Web. Sincerely, Tom -- Tom Wellige wellige(a)itk.de http://www.kst.dit.ie/people/twellige ========================================================================= Subject: Re: TV Pascal Source From: u6ed4(a)wvnvm.wvnet.edu (Cyber-Babushka) Date: 1997/04/18 Message-Id: <Pine.LNX.3.95.970418084428.211A-100000@seraphim> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] On Fri, 18 Apr 1997, Wellige wrote: >A few weeks ago I spoke to someone from Borland Germany and he told me that >the sources are free as long as they are not sold. It's definatley allowed >to publish them e.g. on the Web. In that case, if someone would please send me the Pascal sources, I would be happy to put them on the TVPlus web site as a courtesy. Would someone on the newsgroup please forward this request to the mailing list? My posts never make it through. I think I was put on review or something for posting the pointer to the FAQ too many times without changing it. Problem is, there's no listowner to take me off review, and I've written to the sysop without getting an answer. bonni http://wvnvm.wvnet.edu/~u6ed4/bonni.html C++ Turbo Vision archive: http://brooks.wvn.wvnet.edu/tvhome __ __ IC | XC | bonni mierzejewska "The Lone Quilter" ---+--- | u6ed4(a)wvnvm.wvnet.edu NI | KA | Kelly's Creek Homestead, Maidsville, WV ========================================================================= Subject: Re: TV Pascal Source (was Re: [Q] Need more than integer for TPoint From: codc01(a)gel.usherb.ca (Carl Eric Codere) Date: 1997/04/18 Message-Id: <codc01.255.0008B169(a)gel.usherb.ca> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] In article <5j75uj$53o(a)news.Dortmund.Germany.EU.net> "Wellige" <Wellige(a)itk.de> writes: >A few weeks ago I spoke to someone from Borland Germany and he told me that >the sources are free as long as they are not sold. It's definatley allowed >to publish them e.g. on the Web. Are you sure about this? There has been no official word on this from Borland USA, do you know where I can get more information, since each time I e-mail Borland, I do not get any reply! Carl Eric Codere (aka The Black One) Pascal and asm programming http://www-edu.gel.usherb.ca/codc01 ========================================================================= Subject: Re: TV Pascal Source (was Re: [Q] Need more than integer for TPoint From: "Wellige" <Wellige(a)itk.de> Date: 1997/04/21 Message-Id: <5jf56a$77m(a)news.Dortmund.Germany.EU.net> Newsgroups: comp.os.msdos.programmer.turbovision [More Headers] Carl, >Are you sure about this? There has been no official word on this from Borland >USA, do you know where I can get more information, since each time I e-mail >Borland, I do not get any reply! Thats what the guy from Borland Germany told me: it's ok for Borland to post them in newsgroups when explaining something. So it will be also ok to make them somewhere accessable on the net so one don't have to resend them everytime in a newsgroup. Sincerely, Tom -- Tom Wellige wellige(a)itk.de http://www.kst.dit.ie/people/twellige -- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

New Alpha: EMX run time library broken?
by Peter Gerwinski 23 Apr '97

23 Apr '97

Hello, I was reported that the EMX run time library of the latest alpha GPC (gpc-970420) is broken: Not even `hello.pas' can be linked. Since I cannot reproduce the error on my own system (I can link even more complicated EMX programs here ... :-) I ask whether somebody else has observed the same problem. Perhaps there is a bug which only shows up in some configurations ... Thanks in advance, 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: New Alpha
by Frank Heckenbach 23 Apr '97

23 Apr '97

First of all: Thanks for implementing all the new features and removing many bugs! I like especially the packed arrays and records and the write(ln) with subranges! :-) Most of the bugs I reported in the last few months seem to have gone. However, the following still doesn't work (if it's already/still on the bug list, please ignore): PROGRAM x; CONST n:1..16=6; {"subrange bounds are not of the same type"} {The same with "var ...=...", ok with "var ... value ..."} BEGIN END. Then, a very small problem: I have a Pascal program (let's say foo.pas) that uses some units. I've put the following line into it: {$IFDEF __GPC__}{$automake="-O3"}{$ENDIF} It also needs some C functions contained in bar.c . If I compile it with "gpc foo.pas bar.c", it works fine. But if I do "gpc bar.c foo.pas", it doesn't ("Undefined references" to the C functions). In the latter situation also the file foo.gpc is left. It's no real problem since the first version works, but I just want to make sure if this is supposed behaviour (for any reason) or a little bug. BTW, the problem in Linux that I described is still there, but I solved it (temporarily) by moving cpp to cpp_ and putting the following script as cpp: #!/bin/sh /usr/lib/gcc-lib/i486-linux/2.7.2.1/cpp_ $* -U__GNUC_MINOR__ -D__GNUC_MINOR__=7 Probably not a very elegant solution, but it seems to work for now... -- 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

New Alpha
by Peter Gerwinski 20 Apr '97

20 Apr '97

Hello! Here again is a new GPC alpha version. Changes since gpc-970412: General news: * `Packed' works. A "packed array [ 1..8 ] of Boolean" now occupies one byte instead of 8 like before (or like with Borland Pascal which claims to pack all arrays automatically). Also, the type packed record a: Boolean; b: 0..3; c: -3..3; end; now also has just one byte (instead of 3). :-) As a result, the built-in procedures `pack' and `unpack' are probably broken. Since I have no experience with these procedures, please send me some test programs which do exactly "writeln ( 'OK' )" if everything works, or else "writeln ( 'failed' )" (or crash or don't compile) if not. Thanks in advance. * GPC now has yet another new option `--debug-tree="Foo"' which is useful for debugging GPC itself. I use it to look at GPC's internal information about a variable `foo' during compilation by inserting (*$debug-tree="Foo"*) into the Pascal source. * Implemented more warnings about unrecognized compiler directives or combinations which make no sense. Bug fixes: * Comparisions of ordinal types as `if' conditions work again (was broken in gpc-970412). * `Const' or `protected Var' parameters which are transported through GPI files do not spoil type declarations any more. * Assignment to char type subranges work again. (Was broken, probably in gpc-970215.) * The `write' and `writeln' procedures applied to subranges (e.g. `Char' subranges, `Byte' variables, etc.) work now. Borland Pascal: * Untyped parameters now can be passed as parameters to subsequent functions which also want untyped parameters. Extended Pascal: * GPC now warns about `or else' and `and then', which are GPC extensions, when `--extended-pascal' is given. (ISO Pascal wants `or_else' and `and_then'.) * Assignments <char variable> := <string value> (allowed in EP, not in BP) now work in parameter passing, too. (This means they should work in all situations now.) With `--borland-pascal', a warning is given. * Modules: Exported ranges work. * I herewith present first results from the Schema Project. (-: The following schemata work now: Type MySubrange ( LastChar: Char ) = 'A'..LastChar; MyArray ( n: Integer ) = array [ 1..n ] of Real; (Not yet implemented: `New', `Dispose', and parameter passing with undiscriminated schemata. And probably more.) If you want to contribute to this part of GPC, please test these types of schemata in as many contexts as possible. It is impossible for myself to try this out with all underlying data types, in the context of assignments, other expressions, parameter passing, etc. The source - a diff against gpc-970412 - is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ together with binaries for DOS (DJGPP), DOS and OS/2 (EMX), Linux (ELF), and FreeBSD. Thanks to Abimbola A. Olowofoyeku, Frank Heckenbach, Berend de Boer, and Sven Hilscher for finding the bugs. Again: Is anybody interested to help to document all this? For example, to write a list of Extended Pascal [Borland Pascal] features which work [do not yet work] in GPC which replace the somehow outdated chapter "Extensions", "Extended Pascal", and "Borland Pascal" in the on-line manual? Or to complete and improve the description of the compiler option in chapter "Invoking GPC"? Finally I have one more question: Let's assume the Schema Project to be done. How much compatibility to Extended Pascal and to Borland Pascal can we claim then? In case it is EP > 90% I would like to enter beta test stage and to prepare for the release of gpc-2.1. If not, I would like to know which parts of EP should be implemented to achive > 90% compatibility. (* This condition arises from former announcements where I misunderstood some notes in the GPC source and already claimed 90%. )-: Instead of decreasing this number in future releases I want to improve GPC and announce at least 91% - which must be justified then. We aim the possibility to have 100% EP with `--extended-pascal' anyway. {I aim the 100% only with the switch, because - for instance - this nested comment would be an error in Extended Pascal.;-} *) 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: New Alpha
by Frank Heckenbach 19 Apr '97

19 Apr '97

Peter Gerwinski wrote: > Yes, conditional defines. GPC pre-defines the symbol "__GPC__": > > (*$ifdef __GPC__ *) > (* GNU Pascal switches *) >[...] > (*$else *) > (* Borland Pascal switches *) >[...] > (*$endif *) > > What would you consider "simpler" than this? ;-) OK, if "__GPC__" is predefined, this is viable. I didn't know about this, I tried just "GPC"... > > BTW: Is it legal (with the currect version) to use "gpc foo.c bar.pas"? > > I asked about this already in my mail about "Re: Linking directives..." on > > 3 Apr, but unfortunately got no replies. > > Oh - sorry, I overlooked it. #-) Yes, it's legal, and it works on my > Linux box, too. (You wrote that it didn't work on yours; perhaps this > bug is fixed now?) No, it seems to be an installation problem. Up to now, I could trace it down to the fact that "-D__GNUC_MINOR__=0(2" is passed to cpp if called via gpc, instead of "-D__GNUC_MINOR__=7" with gcc. I'm not sure yet why this is so, does it have anything to do with "gpc version 2.0(2.7.2.1)"? ^^^ -- 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

2 1

New Alpha: libgpc.a for DJGPP
by Peter Gerwinski 17 Apr '97

17 Apr '97

Hello, the runtime library in the DJGPP binary distribution of the last Alpha GPC was bogus. Even `hello.pas' did not work. Sorry for that ... #-) (But the source is okay!) I am updating `gpc-970412.i386-djgppv201.zip' on agnes. Yours, 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 [970412] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: New Alpha
by Peter Gerwinski 16 Apr '97

16 Apr '97

According to Frank Heckenbach: > > BTW: You recently said that one has to use '-pedantic', not '-fpedantic' > in specs. Is there a general rule when to use '-f...' and when simply '-...'? AFAIK, the GNU compiler originally accepted only `-ffoo-bar' flags. (The `-f' stands for "flag".) Nowadays, just `--' is okay as an alternative for `-f'. (Note that these long options start with two dashes, not just one.) The `specs' file only understands the old syntax. `--pedantic' is an exception, because it is originally `-pedantic' (with one dash), not `-fpedantic' (i.e. no "flag" in this sense). To get all options, read the (loooooooooooong) section "Invoking GPC" from the info documentation, and pick up the flags not explained there from my "New Alpha" announcements. In the worst case, look at the GPC source file `gpc-options.h' for a list of all `--' (or `-f') options, and see `gpc-decl.c' for what they do. > Just to make sure: 'AutoMake="--foo"' means that '--foo' is used for the > compilation of the units involved and the program itself, while > 'AutoMake, --foo' would apply '--foo' only to the program. Is that right? Almost. Within the directive, `--' (in fact: `-f') is automatically prefixed, so don't give it explicitly. (*$AutoMake="--foo"*) correct; gives `--foo' to the compilation of Units (*$AutoMake="foo"*) wrong; gives `foo' to the compilation of Units (which is nonsense) (*$AutoMake,foo*) correct; gives `--foo' to the current compilation (*$AutoMake,--foo*) wrong; gives `----foo' (in fact: `-f--foo') to the current compilation. > A minor "problem": If I compile a program with such a compiler switch with TP, > TP complains about an "Invalid compiler directive". Is there a way [...] > to supply the options so that gpc will recognize them and TP will ignore > them? Yes, conditional defines. GPC pre-defines the symbol "__GPC__": (*$ifdef __GPC__ *) (* GNU Pascal switches *) (*$no-field-widths *) (*$AutoMake="--foo --bar"*) (*$N+*) (* Nested comments *) (*$E-*) (* No C-style char escapes *) (*$else *) (* Borland Pascal switches *) (*$M 65536 *) (* Stack size *) (*$N+*) (* Numeric coprocessor on *) (*$E-*) (* Don't link the Emulator *) (*$endif *) (* Switches for both compilers *) (*$B-*) (* Short-circuit Boolean operators *) > (perhaps a simpler way than conditional defines) What would you consider "simpler" than this? ;-) > What about compiler options for "-o foo", "foo.o" and/or "bar.c"? Are you > working on them, or are they too difficult to implement? Working on them. I don't expect much trouble from (*$L foo.o *) and (*$L bar.c *), but I am not so sure about "-o foo" ... > BTW: Is it legal (with the currect version) to use "gpc foo.c bar.pas"? > I asked about this already in my mail about "Re: Linking directives..." on > 3 Apr, but unfortunately got no replies. Oh - sorry, I overlooked it. #-) Yes, it's legal, and it works on my Linux box, too. (You wrote that it didn't work on yours; perhaps this bug is fixed now?) > And another contribution to the GPC test suite... :-| > > The following program and unit cause the latest gpc to fail with SIGSEGV. > It worked with a previous version of gpc [...] I can reproduce the error. Okay, it will be fixed in the next Alpha. (I hope at least.;) 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 [970412] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Boolean operators (Was: Re: New Alpha)
by Peter Gerwinski 16 Apr '97

16 Apr '97

According to Frank Heckenbach: > > Indeed, I think this is good if one uses complete evaluation by default. > However, I prefer to have short circuit evaluation by default. > So what about similar operators to force complete evaluation - it would seem > cleaner to me than using {$B+} ... {$B-}? ISO Pascal's short circuit operators are "and_then" and "or_else"; GPC also allows "and then" and "or else". Perhaps "or_then" and "and_else" would be their natural counterparts? BTW, can anybody tell me a case where complete evaluation is desirable? IMHO, no reasonable Pascal program should use functions with side-effects in `if' conditions containing `and' because you can never know in which order they are evaluated (except with short-circuit operators, but here we are again). ... Ahhh! 8-) PS: ISO 10206, 6.8.3.1 says: NOTE - This means, for example, that the operands [of ordinary `or' and `and'] may be evaluated in textual order, or in reverse order, or in parallel, or they may not both be evaluated. This means that short circuit operators being the default does not break ISO conformance. Fine. :-) AND it means that if you want to produce portable code you cannot rely on complete evaluation, so be careful. 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 [970412] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: BP RTL
by Peter Gerwinski 16 Apr '97

16 Apr '97

According to skye: > I was wondering if anyone has put together a lib for BP compatibility. Try the "BPcompat" package, available at ftp://kampi.hut.fi/jtv/gnu-pascal/contrib/ ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/ 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 [970412] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: BP RTL
by The African Chief 16 Apr '97

16 Apr '97

On Tue, 15 Apr 1997 14:58:26 -0700 skye <s_c(a)iname.com> wrote: >I was wondering if anyone has put together a lib for BP compatibility. A >most-commonly-used-functions one? Something? I'm new to GPC and would like >to use it for my lessons as well as encorage my students to use it. I've >already got them using DJGPP for C/C++. Peter already has a BPCOMPAT package which implements some of the Borland RTL routines. I myself am implementing some more. Some of this has involved importing some functions from the C library. I am also producing Pascal UNITs for many of the C headers (io.h, stdio.h, stdlib.h, ctype.h, dos.h, dir.h, etc). When all this is finished, it will be released to the GPC community. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

BP RTL
by skye 15 Apr '97

15 Apr '97

I was wondering if anyone has put together a lib for BP compatibility. A most-commonly-used-functions one? Something? I'm new to GPC and would like to use it for my lessons as well as encorage my students to use it. I've already got them using DJGPP for C/C++. Thanks, -SC

1 0

Re: New Alpha
by The African Chief 15 Apr '97

15 Apr '97

On Tue, 15 Apr 1997 16:29:10 +0100 David Fiddes <D.J.Fiddes(a)hw.ac.uk> wrote: >>I am writing a shell for GPC - "GPCC.PAS" (in Borland Pascal). All that >it >>does is to parse the command line, parse the source file to see whether >>it is a unit/module or a program (and pass the necessary "-o" or "-c" >>switch accordingly, read a file called "GPCC.CFG", add any switches >found >>in it to the list of parameters obtained from the command line, and then, >>run "GPC" with the whole list of parameters. >> >I thought that gpc was similar to gcc(I'm not that familiar with gpc -- it >won't build with the cygnus source tree I use)..isn't gpc.exe like gcc.exe >in that it's just a shell for ccp.exe and cc1.exe, as.exe, ld.exe >,etc,etc. I presume that GPC is a shell to GPC1, or GPC-CPP, or, to both of them. I am operating from the point of view of someone from a BP background, who does not understand MAKE files or such, but who is comfortable with the idea of a .CFG file that contains all the parameters you wish to always pass (splitting infinitives here?) to a command line compiler. GPCC (the name is insignificant - perhaps it should be GPCS - for "GPC shell") simply provides this facility. It also served the purpose of presenting me with an opportunity to write GPC implementations of many Borland Pascal runtime library functions. This should increase GPC's "Borland" compatibility. >It would be just as easy to write a whole new gnubpc.exe shell...? It would >be cleaner perhaps... This is really what I am trying to do - but I don't want to make it just a Borland extension shell, so it is just a program that reads a file, parses the command line, and sends everything to GPC.EXE. The implementations of Borland RTL functions are in UNITs, which will be usable by everybody (I hope). Presumably, somebody someday will convert the UNITs to EP modules. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: New Alpha
by David Fiddes 15 Apr '97

15 Apr '97

>I am writing a shell for GPC - "GPCC.PAS" (in Borland Pascal). All that it >does is to parse the command line, parse the source file to see whether >it is a unit/module or a program (and pass the necessary "-o" or "-c" >switch accordingly, read a file called "GPCC.CFG", add any switches found >in it to the list of parameters obtained from the command line, and then, >run "GPC" with the whole list of parameters. > I thought that gpc was similar to gcc(I'm not that familiar with gpc -- it won't build with the cygnus source tree I use)..isn't gpc.exe like gcc.exe in that it's just a shell for ccp.exe and cc1.exe, as.exe, ld.exe ,etc,etc. It would be just as easy to write a whole new gnubpc.exe shell...? It would be cleaner perhaps... Dave Dave Fiddes, CALM Software Production Officer Department of Mathematics, Heriot-Watt University, Edinburgh email D.J.Fiddes(a)hw.ac.uk - Tel: 0131-451-3251

1 0

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