Gpc June 1997

gpc@gnu.de

25 participants
172 discussions

Re: CygWin32 and BPCompat
by The African Chief 09 Jun '97

09 Jun '97

On Mon, 9 Jun 1997 12:09:21 +0100 (WET DST) Jan-Jaap van der Heijden <janjaap(a)Wit381304.student.utwente.nl> wrote: > >I have converted just enough headers to be able to compile a basic GUI >application, where you do all the message handling yourself (no object >windows available :-( No sweat about object Windows (something can be done about that later). Can you please send me a copy of your converted headers? Thanks. There is no point in duplicating efforts, and I don't want to reinvent the wheel. >I did this for cygwin32 b16. Then I focussed more on the unix ascpects for >some time, but now I have a b18 GPC compiler, and I'm working on some >cygwin32 things (DLL's, building the RTS as a DLL etc.) I'm not sure that >function attibutes survive through the GPI mechanism (they didn't for >b16) so using units may not be possible. Well, I could simply "$INCLUDE" the sources - which is what I did when I first started using GPC anyway. > You need the >"__attribute__((stdcall))" feature to access win32 API functions. Yes, I saw this in some of the sample programs. >Building DLL's on doze95 is difficult (not just for GPC) in b18. >NT seemed fine, but my NT machine crashed a HD this weekend :-( Ooops! >> PS: >> I have found that many things are different under CygWin from the rest >> (e.g., the "stat" structure; the "errno", which is implemented as a macro); >> and many things which are in standard C headers are missing (e.g., >> strlwr(), strupr(), stricmp, etc.). >> > >cygwin32 is basically BSD. >I don't know about the unix (?) that cygwin32 differs from in your opinion, I was actually comparing it to the emx and djgpp headers - which I suppose I shouldn't. I didn't know that cygwin32 was based on BSD. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 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 The African Chief 09 Jun '97

09 Jun '97

On Sun, 8 Jun 1997 17:03:09 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >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... The objects.pas unit in BPCompat does not zero out things. It actually does some "proper" initialisation :-) So, this is a place where I need to add some "!!!" comments to point out the differences with BP. >> 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? Resource files (at least Windows resource files) can also hold strings in string tables. Most Windows programmers cannot do without these string tables. How would you represent the strings with integers? You need to store the actual strings in the resource file. >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.) Would there be a problem if two or more programmers (unknown to each other) just happened to choose the same ID? I am just asking, because I am not sure whether this will affect anything else or not (it may very well not affect anything). Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: Enumerated types
by Orlando Llanes 09 Jun '97

09 Jun '97

I translated a C program to Pascal once that had enumerated types, and in order to use typedefs like that, you need to re-arrange and improvise. What I did was put all enums as constants and set them to their appropriate values. You might be able to use $define's to acheive the desired effect. ---------- > 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?

1 0

Re: OOP
by Frank Heckenbach 08 Jun '97

08 Jun '97

Peter Gerwinski wrote: > Now suppose, the index 'EditImportantData' were an Integer, say 42. Of > course, there would be a constant declaration `Const EditImportantData = 42' > in some Unit, so the call would be the same but two apostrophies. Okay. > But now we introduce more dialogs which are thematically related to > the 'EditImportantData' dialog, e.g. 'EditEvenMoreImportantData'. A natural > choice for a numeric constant for it would be 43, but that's busy already. > So we can either change *all* numerical constants and recompile the whole > application or declare `Const EditEvenMoreImportantData = 3742' - whatever > is free - which invites for errors when forgetting which numbers represent > which dialogs. As I said, IDs must be chosen with a little more sophisticated mechanism. Since nobody told us anything about these Delphi/Windoze things, I'm just suggesting something. Let's say the ID is a 64 bit integer (if Delphi has 128 bit, that might be more compatible, but I don't know...). So let's say 32 of these 64 bits are a unique programmer ID. The other 32 bits can be used by the programmer as (s)he chooses. So you could use 16 bits as a unique unit ID (I guess you won't write more than 65536 units in your life), and 16 bits as a unique ID per unit (max. 65536 classes per unit). No renumbering necessary ever, even if you included someone else's sources! :-) So you could declare: const JHackerID=$E94F561A00000000; {Your ID, declared once, globally} const JEditorID=JHackerID+$12000000; {For each project} const EditUnitID=JEditorID+$240000; {For each unit} const EditCommandsID=ThisUnitID+$1000; {For each "kind" of IDs} const EditImportantData=EditCommandsID+42; You may or may not need either or all of project or unit level or "kinds" of IDs, that's any programmer's own choice. > > Object(...)[StringID,NumID] > > Why not? Looks reasonable ... Fine! :-) Then we've only got to decide about the size of the NumID. I think 64 or 128 bits are reasonable, but which? > (* However I still think it is the job of the library, not the compiler, > to provide such IDs. *) But typing "const ClassName:^String value @'EditImportantData';" is not very convenient, is it? (Apart from the fact that the syntax "@'...'" doesn't work, does it? So it would be even more complicated to declare, or one would have to use a CString.) Besides, a check for duplicate NumIDs could only be done at runtime. :-( So the compiler could help a little. Since it's only optional (it will not be linked in if not used), I see no disadvantage. > Delphi users: Please help us poor guys to understand how Delphi works, > then there is a chance that you can have all these nice features in GPC, > too, one day. Yes, please! > > 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). > > Think of a large, well-established library. Now somebody wants to modify for > some unexpected situation. Then the programmer (i.e. the user of the library) > can either directly add fields whereever appropriate - then communication with > other applications which use the same library might become complicated - or > use these "hook" fields. I don't understand. Adding fields without code that accesses the new fields doesn't do anything. So if you add the new fields, you'll also have to provide new methods, won't you? So you'll have to derive new classes with the new methods, and those classes get the new fields. That's what one would do normally. > GCC has such extension fields at a number of places: For example, each > structure which represents a "type definition" has one "pointer" field > pointing to a "struct lang_decl" which must be defined by the language > front-end using the GCC back-end. We use this, for example, to store an > additional integer in the type definition node which tells whether something > is a String, a Schema, an Object, a variant Record, or just an ordinary type > - plus some pointers holding Object inheritance information and Schema > discriminants. > > Of course, this could have been achieved by deriving a successor object, > because this happens in the "highest level" of an "object hierarchy": there > are no "successor objects" of the "type definition object". But if there > were, inheritance would not work any more - this "hook" field still would. What kind of successors? AFAICS, these different types (Strings, Schemata, Object, variant Record, ...) *are* the natural descendants of the abstract type "TType". Can you give me an example of another "orthogonal" inheritance? If it is specific only to one language, this language would declare an abstract successor of "TType" with the "hook", which would probably be more specific than just "PObject" then. Other languages wouldn't have the hook. That's one of the main ideas behind OOP: not having to provide "holes" for any unknown future extensions, but being able to add what's needed when it's needed. > I agree that this would be nice, and I think that this would not be as hard > to implement as one would expect on the first guess. (Frank, it's a similar > thing as your suggested `iftype' for accessing variable argument lists.) I know, but AFAIR there wasn't much response to this suggestion. But with objects it seems easier to do than with normal types. > What does The Standard say about this? Actually, which standard? Do you mean Object Pascal? How much does gpc comply to this standard at all? (Up to now, we've only oriented on BP and some ideas of our own, haven't we?) -- 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

Machine Code...
by Orlando Llanes 08 Jun '97

08 Jun '97

I was wondering if there was a way to insert Machine Code into a GPC Program. The reason is that I'm trying to duplicate Borland Pascal's Port array by using 2 functions, one for port input, one for port output. My problem is that when I type "asm( 'inb %al, %dx' );" the compiler says "386 instruction not recognized" I tried using an INLINE statement, that didn't work either, I even tried "asm( '$EC' );" which is the machine code equivalent, still nothing, then I tried "asm( 'db $EC' );" which didn't do it either. 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! See ya! Orlando Llanes

2 1

Re: Procedural types
by Peter Gerwinski 08 Jun '97

08 Jun '97

According to Bernhard Tschirren: > > 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. You mean: *Pointers* to procedures like implemented in gpc-2.0- don't allow `Var' parameters. Recent alpha versions allow both pointers to procedures with `Var' parameters as well as BP-stype "procedural variables": Type MyProc = Procedure ( Var x: Real ); MyProcPtr = ^Procedure ( Var x: Real ); (* `Var' parameter *) 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: Exit extension.
by Peter Gerwinski 08 Jun '97

08 Jun '97

According to Bernhard Tschirren: > > I have always missed (in BP) an extension to Exit in the form of > Exit(RetValue), just like C's return. GPC has `Return ( RetValue )'. :-), 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: Enumerated types
by Peter Gerwinski 08 Jun '97

08 Jun '97

According to Bernhard Tschirren: > > Is it possible to specify the value of an enumerated type? AFAIK, this is not possible. Enumerated types are used whenever something abstract is needed where the numeric value does not matter. > 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 > ... I would translate it into a forest of constants. If everybody agrees that there should be an extension like this in GPC: It's probably not so hard to implement. Suggestions for the syntax? Objections against it? 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 08 Jun '97

08 Jun '97

According to Frank Heckenbach: > > 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? BO4 has the following `ExecDialog' procedure: Function ExecDialog ( Index: String; Data: Pointer ): Word; It gets the dialog from the resource file at index `Index' and lets it work on the data pointed to by `Data'. The return value is the command the user entered to leave the dialog. It's quite similar to TV's ExecDialog, except that you don't pass a pointer to the dialog but an index to the resource file - the object's ID. A typical call: Var MyImportantData: record foo, bar: Real; end (* MyImportantData *); if ExitDialog ( 'EditImportantData', @MyImportantData ) <> cmCancel then UpdateEverything; Now suppose, the index 'EditImportantData' were an Integer, say 42. Of course, there would be a constant declaration `Const EditImportantData = 42' in some Unit, so the call would be the same but two apostrophies. Okay. But now we introduce more dialogs which are thematically related to the 'EditImportantData' dialog, e.g. 'EditEvenMoreImportantData'. A natural choice for a numeric constant for it would be 43, but that's busy already. So we can either change *all* numerical constants and recompile the whole application or declare `Const EditEvenMoreImportantData = 3742' - whatever is free - which invites for errors when forgetting which numbers represent which dialogs. > [...] > > So both IDs could coexist peacefully... :-) > > Syntax proposal: > > Object(...)[StringID,NumID] Why not? Looks reasonable ... (* However I still think it is the job of the library, not the compiler, to provide such IDs. *) > [QueryInterface, etc. ...] Delphi users: Please help us poor guys to understand how Delphi works, then there is a chance that you can have all these nice features in GPC, too, one day. > 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). Think of a large, well-established library. Now somebody wants to modify for some unexpected situation. Then the programmer (i.e. the user of the library) can either directly add fields whereever appropriate - then communication with other applications which use the same library might become complicated - or use these "hook" fields. > > [Example: GCC compiler back-end ...] > > 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. GCC has such extension fields at a number of places: For example, each structure which represents a "type definition" has one "pointer" field pointing to a "struct lang_decl" which must be defined by the language front-end using the GCC back-end. We use this, for example, to store an additional integer in the type definition node which tells whether something is a String, a Schema, an Object, a variant Record, or just an ordinary type - plus some pointers holding Object inheritance information and Schema discriminants. Of course, this could have been achieved by deriving a successor object, because this happens in the "highest level" of an "object hierarchy": there are no "successor objects" of the "type definition object". But if there were, inheritance would not work any more - this "hook" field still would. > [Implicit type cast with `is' operator ...] > > 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: I agree that this would be nice, and I think that this would not be as hard to implement as one would expect on the first guess. (Frank, it's a similar thing as your suggested `iftype' for accessing variable argument lists.) What does The Standard say about 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 [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

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

← Newer
1
...
10
11
12
13
14
15
16
17
18
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc June 1997