Frank Heckenbach wrote:
Peter N Lewis wrote:
The biggest challenges I'm facing are:
Lack of univ parameter support (I see Sun Workshop Compiler docs <http://www.ictp.trieste.it/~manuals/programming/sun/pascal/lang_ref/ ref_proghead.doc.html#742>, so it is not just Mac Pascals).
At first glance, it seems to be different. AFAIUI, the Mac Pascal version requires the same size for the parameter. This page says:
: univ is most often used for passing arrays, where you can call a : procedure or function with different array sizes. In that case, : you generally would pass another parameter that gives the actual : size of the array, as follows:
I.e., obviously not the same size. The example is about a var-parameter (where internally a pointer is passed, so in this regard the size is the same), but it doesn't seem to say that the statement applies only to var-parameters.
BTW, I think the example is pretty bad anyway. Why "convert" (by using univ) a variable-size array to 1..100? When the actual parameter is larger, the code would fail with a spurious range-check error. If they want to allow for variable array sizes, they should have used a conformant array parameter, which according to this page, this compiler supports as well. And, given the example as it is written, wouldn't the compiler allow for any type for the actual parameter (not only array [1 .. something] of real)? This would be really bogus.
Anyway, implementing it for different-size value parameters would be hazardous AFAICT, and I can't imagine anybody really wants this.
I agree that value parameters should have the same size.
So what do you really need? I think defining a sane subset might be the only way out of this long-standing dilemma. Types that happen to have the same size on a given platform, e.g. a pointer and some integer type, seem too fragile, and I can't easily imagine a good use for such conversions.
I don't see a reason why a conversion from a pointer to an integer type is "too fragile". If the compiler checks the sizes, the only risk is an error messages when sizes ever change. Yes, I agree that it is not "good style" for platform independent code, but even then the decision is up to the programmer. I value that GPC is great for writing platform-independent code, but we have to be realistic too. As of today, this only applies to non-GUI programs. As soon as you start to write GUI applications, the software is heavily dependent on the OS and platform-independence is no longer an argument, because you have made a decision beforehand on what platforms the software should run.
I will be quite happy if, at some point in the future, we will be able to write high-quality platform-independent GUI software for all platforms using GPC and GtK, Qt, GNU Step, Lazarus or whatever framework, but even then we should think about the many millions of lines of code that have been written already - and that we don't want to throw away, because it took us many years of our life and utmost devotion to write.
OTOH, all pointer types (in GPC) always have the same size, so converting between pointers would be less risky, and more meaningful. Is this sufficient? What kinds of parameters are required, only value, or also var paremeters?
Both value and var parameters.
And if we could restrict it to pointers, do I get it right that the routine externally behaves as if the parameter were an untyped pointer (i.e., `Pointer' in BP and GPC), and internally the pointer is converted to the given type before the routine starts?
There is also the unfortunate case (discussed long ago) where an untyped 'Pointer' parameter of a formal procedural parameter is rejected by the compiler when the corresponding pointer parameter of the actual procedural parameter is typed.
Lack of {$unused( param )} directive - needs to be commended out with ifdef __GPC__ for each one (and then I don't understand why GPC is not itself warning about the unused parameters...)
Nomally it does with -Wunused-parameters (or -Wall which includes it). Did you use this option? If so, can you provide an example?
Isn't at least -O1 required when checking for unused parameters (etc.)
Regards,
Adriaan van Os