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?

Robert

AdjuntoTamaño
Descargar oopw.txt3.7 KB
publicaciones de 8 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

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)

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.

Steve

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

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.

Robert

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.

Steve

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

Inicie sesión para dejar un comentario.