That's exactly how the original WinAPI does it. All handles are pointers to their own dummy structures. The current druntime WinAPI just aliases all handle types to HANDLE, which is itself an alias to void*. This is very wrong.


On Fri, Nov 23, 2012 at 5:58 PM, Vladimir Panteleev < vladimir@thecybershadow.net> wrote:

> On Friday, 23 November 2012 at 13:57:14 UTC, Vladimir Panteleev wrote:
>
>> If breaking code were not an issue, the best solution would be to make HANDLE a unique, opaque type (like a struct wrapping an intptr_t or void*) - which is exactly how it should be treated. It would need to support assignment/creation from "null" though.
>>
>
> Oh, I think I remembered. I believe the proper solution is to create a dummy struct type, and make HANDLE a const pointer to it. Then it cannot be confused with other types, but still accepts null assignments.
>



-- 
Bye,
Gor Gyolchanyan.

11/23/2012 4:56 PM, Andrej Mitrovic пишет:
> On 11/23/12, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
>> It'll take more time trying to extract stuff from Derelict, rather then
>> regexp search/replace -ing the headers.
>
> You really believe that your regex script is going to do a better job
> than what Mike has been using and maintaining for years? The same
> applies to WinAPI, these bindings have been developed and used in
> years. Introducing new bindings to the same APIs which aren't
> compatible with existing bindings is just going to create
> compatibility issues when you use multiple libraries, and it's going
> to create confusion for new users.
>
> Instead of trying to reinvent, why not just contribute to the existing
> bindings if they're missing functionality or some of their code is
> outdated?
>
> I'll also say that IMO the concept of Deimos turns out to be a bad
> idea, and I'm not alone in thinking this. Only few people have write
> access, which means all pull requests have to go through a handful of
> people who may not even know what the code in the bindings does, and
> if the devs aren't around you'll have to wait days or even months (see
> dmd/druntime/phobos) for a pull to be merged. Now some projects use
> module names without a root (module curses), others encode the deimos
> name (module deimos.zmq.utils), and then others use their own encoding
> (module libexif.exif_byte_order).
>
> And then you have Walter which merges all pull requests without any
> review whatsoever. Deimos should have been a wiki page that lists
> active bindings. And each binding project would have a maintainer or a
> team of maintainers (who would review pull requests properly). And
> that's it.
>
+1

Hope the new wiki will come along nicely.
-- 
Dmitry Olshansky

On Friday, 23 November 2012 at 12:57:01 UTC, Andrej Mitrovic wrote:
> I'll also say that IMO the concept of Deimos turns out to be a bad idea, and I'm not alone in thinking this.

I don't think I agree with you here. The idea of Deimos, i.e. a central repository of "no-fluff" C bindings (which are relatively static in nature anyway), is not bad at all. It is just the execution that could be improved.

For example, yes, I think it would definitely make sense to give the original authors push access after an initial review. And yes, a unified directory structure is sorely needed to get the most out of the Deimos concept.

But still, I don't see why this would make Deimos a bad idea at all.

David

Am 23.11.2012 15:03, schrieb Gor Gyolchanyan:
> That's exactly how the original WinAPI does it. All handles are pointers
> to their own dummy structures. The current druntime WinAPI just aliases
> all handle types to HANDLE, which is itself an alias to void*. This is
> very wrong.
>
>
> On Fri, Nov 23, 2012 at 5:58 PM, Vladimir Panteleev
> <vladimir@thecybershadow.net <mailto:vladimir@thecybershadow.net>> wrote:
>
>     On Friday, 23 November 2012 at 13:57:14 UTC, Vladimir Panteleev wrote:
>
>         If breaking code were not an issue, the best solution would be
>         to make HANDLE a unique, opaque type (like a struct wrapping an
>         intptr_t or void*) - which is exactly how it should be treated.
>         It would need to support assignment/creation from "null" though.
>
>
>     Oh, I think I remembered. I believe the proper solution is to create
>     a dummy struct type, and make HANDLE a const pointer to it. Then it
>     cannot be confused with other types, but still accepts null assignments.
>
>
>
>
> --
> Bye,
> Gor Gyolchanyan.

This kind of reminds me of the way Microsoft "improved" Win16 by using #define STRICT, thus making void* into incompatible structures, which were still size compatible.

This way lots of assignment problems were easily caught during build time.

Oh the wonders of Win16 C development!

--
Paulo

On Friday, 23 November 2012 at 16:32:17 UTC, David Nadlinger wrote:
> On Friday, 23 November 2012 at 12:57:01 UTC, Andrej Mitrovic wrote:
>> I'll also say that IMO the concept of Deimos turns out to be a bad idea, and I'm not alone in thinking this.
>
> I don't think I agree with you here. The idea of Deimos, i.e. a central repository of "no-fluff" C bindings (which are relatively static in nature anyway), is not bad at all. It is just the execution that could be improved.
>
> For example, yes, I think it would definitely make sense to give the original authors push access after an initial review. And yes, a unified directory structure is sorely needed to get the most out of the Deimos concept.
>
> But still, I don't see why this would make Deimos a bad idea at all.
>
> David

Deimos seems like a great idea to me too, and I also agree it will need to be re-organized to allow updates to happen a lot faster. I can understand being overly cautious with the language and compiler, but C bindings are not in the same category by a long shot and need to be maintained by the people who actually use them.

--rt

On 11/23/2012 3:46 AM, Gor Gyolchanyan wrote:
> I hope the deimos folks make a repo soon, so that people can use those modules
> as soon as possible, because I'll finish translating them today.

https://github.com/D-Programming-Deimos/OpenGL

On 11/23/2012 5:10 AM, Gor Gyolchanyan wrote:
> If the only problem with Deimos is the speed at which libraries end up there,
> why not make the review process more loose and allow the code to be submitted
> and then fixed as necessary? It would be much more useful, then just having
> nothing at all.

It is pretty loose. Myself, Andrei, and Brad can merge pulls on it.

There are currently no open pull requests for Deimos.

On 11/23/2012 5:57 AM, Vladimir Panteleev wrote:
> There might be some incompatibilities, for example due to how the HANDLE type is
> declared. In C, you can use either 0 or NULL as a parameter to a function
> accepting an integer or pointer. In D, you cannot. IIRC, some types were
> declared differently in Druntime's modules and in the win32 bindings.
>
> If breaking code were not an issue, the best solution would be to make HANDLE a
> unique, opaque type (like a struct wrapping an intptr_t or void*) - which is
> exactly how it should be treated. It would need to support assignment/creation
> from "null" though.

This is why I don't approve of attempts to "fix" Windows APIs. It winds up being incompatible here and there, and breaks things.

We all know what HANDLE should be, but it isn't. The D definition of HANDLE should match what Microsoft's windows.h declares it as.

Any attempt to fix APIs to C libraries, etc., should be in a separate layer that goes on top of the D interface to those APIs.

Thank you!!!


On Sat, Nov 24, 2012 at 1:15 AM, Walter Bright <newshound2@digitalmars.com>wrote:

> On 11/23/2012 3:46 AM, Gor Gyolchanyan wrote:
>
>> I hope the deimos folks make a repo soon, so that people can use those
>> modules
>> as soon as possible, because I'll finish translating them today.
>>
>
> https://github.com/D-**Programming-Deimos/OpenGL<https://github.com/D-Programming-Deimos/OpenGL>
>
>


-- 
Bye,
Gor Gyolchanyan.

in WinAPI each type of handle has it's own type. in Druntime it's all aliased to void*. It currently doesn't match WinAPI.


On Sat, Nov 24, 2012 at 1:21 AM, Walter Bright <newshound2@digitalmars.com>wrote:

> On 11/23/2012 5:57 AM, Vladimir Panteleev wrote:
>
>> There might be some incompatibilities, for example due to how the HANDLE
>> type is
>> declared. In C, you can use either 0 or NULL as a parameter to a function
>> accepting an integer or pointer. In D, you cannot. IIRC, some types were
>> declared differently in Druntime's modules and in the win32 bindings.
>>
>> If breaking code were not an issue, the best solution would be to make
>> HANDLE a
>> unique, opaque type (like a struct wrapping an intptr_t or void*) - which
>> is
>> exactly how it should be treated. It would need to support
>> assignment/creation
>> from "null" though.
>>
>
> This is why I don't approve of attempts to "fix" Windows APIs. It winds up being incompatible here and there, and breaks things.
>
> We all know what HANDLE should be, but it isn't. The D definition of HANDLE should match what Microsoft's windows.h declares it as.
>
> Any attempt to fix APIs to C libraries, etc., should be in a separate layer that goes on top of the D interface to those APIs.
>



-- 
Bye,
Gor Gyolchanyan.