Tweet
Hello all,
When dealing with some of the Windows internals, the APIs often use an "opaque pointer", which is a pointer
returned by the API to some unknown (to the client) structure, the details of which are unimportant to the
client. For example, in the SETUPAPI.H file:
From a PB point of view I could just declare this as a LONG or a DWORD, but it isn't always clear what the
DWORD is actually pointing to.
My question is, since PB doesn't support TYPEDEFs, could I replace the simple LONG/DWORD declaration with a
TYPE that contains a LONG/DWORD and thereby gain some code clarity? From the compiler's perspective, are the
two the same or is there extra overhead with the TYPE statement?
In my current project I've got a number of these opaque pointers in use, and while
using descriptive variable names helps, it's still something of a mess.
Thanks!
------------------
Mark Newman
When dealing with some of the Windows internals, the APIs often use an "opaque pointer", which is a pointer
returned by the API to some unknown (to the client) structure, the details of which are unimportant to the
client. For example, in the SETUPAPI.H file:
Code:
// // Define type for reference to device information set // typedef PVOID HDEVINFO;
DWORD is actually pointing to.
My question is, since PB doesn't support TYPEDEFs, could I replace the simple LONG/DWORD declaration with a
TYPE that contains a LONG/DWORD and thereby gain some code clarity? From the compiler's perspective, are the
two the same or is there extra overhead with the TYPE statement?
Code:
TYPE HDEVINFO
P AS DWORD
END TYPE
LOCAL tHdev as HDEVINFO
tHdev.P = SomeFunctionThatReturnsOpaquePtr()
SomeSubThatUsesOpaquePtr(tHdev.P)
using descriptive variable names helps, it's still something of a mess.
Thanks!
------------------
Mark Newman
Comment