Gpc May 1997

gpc@gnu.de

30 participants
111 discussions

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

← Newer
1
2
3
4
5
6
7
8
...
12
Older →

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