digitalmars.D - The Win32 HANDLE type under D2
- Stewart Gordon (8/8) Feb 04 2012 Under D1, std.c.windows.windows has HANDLE it as a typedef of void*. Wh...
- Yao Gomez (14/26) Feb 04 2012 Just use the Win32 API way when STRICT is defined:
-
Stewart Gordon
(38/42)
Feb 05 2012
- Stewart Gordon (9/11) Feb 05 2012 I was wrong - it doesn't allow an arbitrary handle to be passed to a fun...
- Zachary Lund (3/14) Feb 05 2012 I don't see a reason to create a "better" way other than abstraction,
Under D1, std.c.windows.windows has HANDLE it as a typedef of void*. While I forget whether they're actually pointers. I guess it fits given that the C headers define it as void* and that handles are fundamentally different from pointers from an app's point of view. Under D2, core.sys.windows.windows has it as an alias of void*. In the WindowsAPI bindings, the definition of HANDLE is versioned to this effect. But there ought to be a better way of dealing with it. Anyone got any thoughts? Are there any plans at the moment for the future of the HANDLE type? Stewart.
Feb 04 2012
On Saturday, 4 February 2012 at 19:32:26 UTC, Stewart Gordon wrote:Under D1, std.c.windows.windows has HANDLE it as a typedef of void*. While I forget whether they're actually pointers. I guess it fits given that the C headers define it as void* and that handles are fundamentally different from pointers from an app's point of view. Under D2, core.sys.windows.windows has it as an alias of void*. In the WindowsAPI bindings, the definition of HANDLE is versioned to this effect. But there ought to be a better way of dealing with it. Anyone got any thoughts? Are there any plans at the moment for the future of the HANDLE type? Stewart.Just use the Win32 API way when STRICT is defined: --- struct HANDLE__{ int unused; } alias HANDLE__* HANDLE; --- for different handles, just create a template that creates different handles with different names: --- mixin DEFINE_HANDLE("HWND"); // struct HWND__{ int unused; } // alias HWND__* HWND; ---
Feb 04 2012
On 04/02/2012 19:40, Yao Gomez wrote: <snip>Just use the Win32 API way when STRICT is defined: --- struct HANDLE__{ int unused; } alias HANDLE__* HANDLE;<snip> Looking through MinGW, this is the code: #ifdef STRICT typedef void *HANDLE; #define #else typedef PVOID HANDLE; #define DECLARE_HANDLE(n) typedef HANDLE n #endif so a HANDLE is just a void*, but DECLARE_HANDLE creates a struct as you describe. This seems to be a hack to create a strong typedef in C, which works as long as the base type is void*. Unfortunately, types (such as HGDIOBJ) can't by this means be made subtypes of HANDLE and then have subtypes of their own (such as HBRUSH, HPEN, HBITMAP). So HGDIOBJ has just been made a void*. But is its being void* in the first place because it's actually a pointer, or is it a hack to accommodate subtypes in this way? (I've a recollection of a handle being just an integer in Win16.) FWIW I've just been experimenting with this idea ----- struct HANDLE { void* h; alias h this; } template DECLARE_HANDLE(string name, base = HANDLE) { mixin ("struct " ~ name ~ " { " ~ base.stringof ~ " h; alias h this; }"); } mixin DECLARE_HANDLE!("HWND"); mixin DECLARE_HANDLE!("HGDIOBJ"); mixin DECLARE_HANDLE!("HPEN", HGDIOBJ); ----- but found that it allows implicit conversions between all handle types, not just up the hierarchy. Is this a bug? Stewart.
Feb 05 2012
On 05/02/2012 16:13, Stewart Gordon wrote: <snip>but found that it allows implicit conversions between all handle types, not just up the hierarchy. Is this a bug?I was wrong - it doesn't allow an arbitrary handle to be passed to a function accepting a specific handle type, but it does allow arbitrary assignment between them. Defining an opAssign in the struct deals with the latter issue. Anyway, what do you think of my idea? Should it be put into the Win32 bindings? Or would doing so break too much existing code? Or should we wait until we have a library typedef and use that? Stewart.
Feb 05 2012
On 02/04/2012 01:32 PM, Stewart Gordon wrote:Under D1, std.c.windows.windows has HANDLE it as a typedef of void*. While I forget whether they're actually pointers. I guess it fits given that the C headers define it as void* and that handles are fundamentally different from pointers from an app's point of view. Under D2, core.sys.windows.windows has it as an alias of void*. In the WindowsAPI bindings, the definition of HANDLE is versioned to this effect. But there ought to be a better way of dealing with it. Anyone got any thoughts? Are there any plans at the moment for the future of the HANDLE type? Stewart.I don't see a reason to create a "better" way other than abstraction, which depending on what you're wanting, has possibly already been made.
Feb 05 2012