Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29398 Discussions

Window programming in object-oriented mode

Robert_van_Amerongen
New Contributor III
1,543 Views

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?

Robert

0 Kudos
7 Replies
JVanB
Valued Contributor II
1,543 Views
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 Then get_address(ow%WndProc) may do what you want. (untested)
0 Kudos
Steven_L_Intel1
Employee
1,543 Views
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.
0 Kudos
Robert_van_Amerongen
New Contributor III
1,543 Views
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. Robert
0 Kudos
JVanB
Valued Contributor II
1,543 Views
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.
0 Kudos
Robert_van_Amerongen
New Contributor III
1,543 Views
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. Robert
0 Kudos
Steven_L_Intel1
Employee
1,543 Views
Robert, 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.
0 Kudos
Robert_van_Amerongen
New Contributor III
1,543 Views
Steve, 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. Robert
0 Kudos
Reply