www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The Win32 HANDLE type under D2

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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
next sibling parent reply "Yao Gomez" <yao.gomez gmail.com> writes:
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
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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;

Looking through MinGW, this is the code: #ifdef STRICT typedef void *HANDLE; #define DECLARE_HANDLE(n) typedef struct n##__{int i;}*n #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
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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
prev sibling parent Zachary Lund <admin computerquip.com> writes:
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