According to Frank Heckenbach:
According to The African Chief:
According to Frank Heckenbach:
(Is there a way to test in a program, if "--borland-pascal" or "--delphi" was given?)
I know of none.
If there isn't, could you make one, Peter? (Perhaps just some predefined symbols?)
What about `__BORLAND_PASCAL__' and `__DELPHI__' (and `__EXTENDED_PASCAL__' and `__STANDARD_PASCAL__' etc. which are of course useless because these dialects don't allow conditional defines anyway;-)?
True enough. In BP, when {$X+} is used, you can use functions just like procedures. Perhaps Peter can add this to GPC as well, so that no warning is generated in such instances? If this happens, then we don't need to turn off warnings.
This was one of the very first things I did to GPC. It was in version 1.1-turbo-alpha-1.0, aka turbo-gpc-2.6.3.tar.gz, aka turbo11b.zip.
Everybody, PLEASE check what GPC can already do and what it cannot BEFORE you post to this list. You are confusing possible GPC newcomers! ;-)
Perhaps (additionally) a separate switch for those who want to use functions as procedures, but without the "risks" implied by "{$X+}" in other aspects? I guess, most of my units would use such a switch.
Ignoring a function's return value *is* a risky thing, because it switches off an error-checking rule which is important for teaching. Programmers who want to use this feature usually (should;-) know what they are doing, and won't be hit by the other "risky" things. For instance: A beginner might unintentionally increment a pointer instead of the value pointed to. An expert probably won't - he produces much uglier bugs.
So I'm asking the asm experts here:
I am not an asm expert, but here are my guesses.
- First, the asm syntax -- can it change, or will it always work like that?
It won't change. To much GCC stuff depends on the asm syntax as it is now, and GPC will stay compatible to GCC. Maybe, somebody will implement an alternative Borland-compatible asm syntax, but this will be an extension. (And, since I now know the advantages of GPC's asm syntax, I won't even vote for doing that.)
- Could using 8 and 16 bit registers ever be a problem (note: that's only for __DJGPP__ and __EMX__)?
No. (Note: That's only for iX86-platforms.)
- Is calling the Dos interrupt like I did it ok, or is there a better way (perhaps some DPMI calls
Praxis has shown for me that interrupts which don't pass pointers work without any DPMI magic. But take care of clobbered registers!
-- perhaps even without any asm, that would be better).
No. This would be *very* system-dependent, so it should not be a GPC built-in.
As a preliminary solution for the overloading problem, one could use
The only way to do it (AFAICS) are include files, or defines on the command line. (BTW: does "-Drandom=RandReal" or such work, or could it be made to work?)
It does work.
Would it seem reasonable (and feasible) to propagate defines (either all of them, or only those that are specially marked) through .gpi files?
No. Defines are C. We do Pascal.
However, it would be desireable to allow inline functions transported through GPI files which have the same functionality (including translating C macros) but are *much* cleaner. To achieve this, somebody would have to extend my `store_tree()' (in `gpc-module.c') to store function bodies in GPI files, too.
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]
-
Peter Gerwinski