Gpc

gpc@gnu.de

5400 discussions

CygWin32 and BPCompat
by The African Chief 09 Jun '97

09 Jun '97

Hi all, I have just succeeded over the weekend to compile SYSTEM.PAS, STRINGS.PAS, AND OBJECTS.PAS with CygWin. This has required some $IFDEFs and the addition of some new functions, just for CygWin - (so, AFAIK, the SYSTEM unit in BPCompat now compiles correctly under DJGPP, EMX, Linux, and CygWin - any other successes?) One thing which I am missing is the Win32 API in Pascal. Has anyone translated any of the CygWin32 C headers (esp. any Win32 API calls) to GPC? I would like to start a collection of these. Better still, is anyone willing to write a program that will parse a CygWin32 C headers and generate a GPC unit from it? Thanks. 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.). 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

2 1

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

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