johnson@p.cs.uiuc.edu (08/23/89)
Jonas Nygren shows that structures with pointers to functions handle my windowing example very well, and says that this proves that object-oriented programming can be simulated without case statements and that run-time binding is not needed. However, he proves my point. Calling a function stored in a structure IS run-time binding. He is just showing how to do object-oriented programming in C. It is fine to do object-oriented programming in C, and some people prefer that to using C++. Many, if not most, languages do not allow pointers to functions to be stored in structures. In particular, Ada does not. In those cases, you have to use case statements. Ralph Johnson
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (08/25/89)
From article <130200009@p.cs.uiuc.edu>, by johnson@p.cs.uiuc.edu: > Many, if not most, languages do not allow pointers to functions to > be stored in structures. In particular, Ada does not. This is one of the proposed Ada 9X revisions, and I think there is a fairly high probability that it will get through. However, it is important to note that the 'ADDRESS attribute provides almost the same thing (ANSI/MIL-STD-1815A, Appendix A, paragraph 2): P'ADDRESS For a prefix P that denotes an object, a program unit, a label, or an entry: Yields the address of the first of the storage units allocated to P. For a subprogram, package, task unit, or label, this value refers to the machine code associated with the corresponding body or statement. For an entry for which an address clause has been given, the value refers to the corresponding hardware interrupt. The value of this attribute is of the type ADDRESS defined in the package SYSTEM. (See 13.7.2.) A value of type ADDRESS can then be converted to an arbitrary pointer type through the use of UNCHECKED_CONVERSION. The major restriction, then, is not an inability to store a pointer to a function in a record type; rather, it is the fact that there is not a mechanism which can express the desire to invoke the function residing at that address; the 9X proposed revision would therefore provide such a mechanism. Bill Wolfe, wtwolfe@hubcap.clemson.edu
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (08/27/89)
From an earlier article by me: > [regarding storing pointers to subprograms in Ada] > The major restriction, then, is not an inability to store a pointer to > a function in a record type; rather, it is the fact that there is not > a mechanism which can express the desire to invoke the function residing > at that address; the 9X proposed revision would therefore provide such a > mechanism. Actually, even this isn't strictly true; since Ada provides a mechanism for arbitrary machine-code insertions, it is quite possible to load the address of the desired subprogram into a register, direct the CPU to execute the subprogram, and finally store a pointer to the results for subsequent use; it's just that there's no way to do it while still preserving portability... Bill Wolfe, wtwolfe@hubcap.clemson.edu
eachus@mbunix.mitre.org (Robert Eachus) (08/29/89)
In article <6339@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From an earlier article by me: >> [regarding storing pointers to subprograms in Ada] >> The major restriction, then, is not an inability to store a pointer to >> a function in a record type; rather, it is the fact that there is not >> a mechanism which can express the desire to invoke the function residing >> at that address; the 9X proposed revision would therefore provide such a >> mechanism. > > Actually, even this isn't strictly true; since Ada provides a > mechanism for arbitrary machine-code insertions, it is quite > possible to load the address of the desired subprogram into a > register, direct the CPU to execute the subprogram, and finally > store a pointer to the results for subsequent use; it's just that > there's no way to do it while still preserving portability... Try the following trick: ..... function Something_or_Other (X: in Integer) return Integer; SOO_Address: Address := Something_or_Other'ADDRESS; procedure Foo (Some_Address: System.Address; T in out Integer) is function Local (X: in Integer) return Integer; pragma INTERFACE(C, Local); for Local'ADDRESS use Some_Address; begin T := Local(T); end Foo; .... The LRM says that this is legal Ada (assuming C is a legal argument to pragma INTERFACE), but it doesn't mandate the semantics. However, I can't imagine any compiler not calling Something_or_Other at the point of the call to Local. The calling conventions on a particular machine may be different for C and Ada though. In fact some compilers permit pragma INTERFACE(Ada,....) for just this reason... Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...