Window programming in object-oriented mode

Window programming in object-oriented mode

I tried to make a window program in as much as possible object-oriented style. Most things went fine, but the compiler complains if I try to handle the window procedure as a type-bound procedure (of course, with the NOPASS-attribute). There is an internal compiler error and the request to contact Intel for support. (If I threat the window procedure as a regular module procedure instead, there is no problem at all.) Enclosed is an example that fails with the recent compiler version.

So the question now is: what is going on here? Has my program a programming error? Is it basically not possible to use window procedures as type-bound procedures? Or something else?


Downloadtext/plain oopw.txt3.7 KB
8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I suppose it's the LOC(ow%WndProc) that gives you the problem? I can see how this could be an issue for a procedure pointer component because there could be a question of which level of indirection you wanted: the address where the descriptor for the procedure is stored within ow, or the address of the procedure pointed at by ow%WndProc. For the syntax in your example there need not be any storage in ow for the procedure, so it should not be a problem. As a workaround, have you tried passing ow%WndProc as an actual argument to a function which takes a procedure dummy argument? Something like:

function get_address(proc)
use iso_c_binding
integer(c_intptr_t) get_address
procedure() proc
get_address = LOC(proc)
end function get_address


get_address(ow%WndProc) may do what you want. (untested)

What you want here is LOC(wndProc). I'd have to think for a bit to determine whether it even makes sense to do LOC of a type-bound procedure, but the compiler should either accept it or give a useful error message. I will report the ICE to the developers. Issue ID is DPD200237944.

I would also encourage you to read my tale of using contained procedures as Windows callbacks, though in your case, there is no dynamic context.

Retired 12/31/2016

Thank you both for your replies.

I have tried the suggestion by Repeat Offender, but that failed. The line get_address(ow%WndProc) generates error #8381 saying that a type-bound procedure cannot be an actual argument. As you may have noted, this is not an urgent question, it was just a try to see whether a callback routine can be in the form of a type-bound procedure. If not: a module procedure is the alternative and that works as desired. I will wait how the issue turns out: error or not.

Again thanks for your kind help.


I can't understand that error.
R1223: actual-arg is proc-component-ref
R739: proc-component-ref is scalar-variable % procedure-component-name
In f2003, these were R1221 and R741, but it seems like type-bound procedures should be OK as actual arguments at least since the time type-bound procedures were added to the standard.

Repeat Offender,

thank you for your reply. I am afraid that I can not comment on this not to mention explain this behaviour.. I have added a modified version of the original program. There you will find a new module procedure get_address that causes the error as described earlier.



The problem with %LOC of a type-bound procedure will be fixed in a future major version. This is an extension - generally, the language does not allow you to take the address of a TBP.

It is also true that type-bound procedures cannot be passed as actual arguments and cannot be targets of procedure pointer assignments.

Retired 12/31/2016


it is good to know that the standard forbits taking a tbp as an argument in any function call. And I am glad to hear that Intel helps us to circumvent this problem in an elegant fashion (unless one persist in strict standard-conforming syntax.)

Tnank for your kind help.


Leave a Comment

Please sign in to add a comment. Not a member? Join today