On 10/26/2013 9:09 PM, Benjamin Thaut wrote:
> Am 25.10.2013 15:10, schrieb Lionello Lunesu:
>>
>> 1. enum names vs prefixes
>> enum FOO { FOO_A, FOO_B }; -> enum FOO {A,B}
>>
>
>
> I actually do number 1 whenever creating C bindings. Because its not
> really DRY to write: FOO.FOO_A
>

alias FOO = int;
enum { FOO_A, FOO_B };

Otherwise, it doesn't match the C API.

On 2013-10-26 14:52:42 +0000, Mike Parker <aldacron@gmail.com> said:

> On 10/26/2013 9:09 PM, Benjamin Thaut wrote:
>> Am 25.10.2013 15:10, schrieb Lionello Lunesu:
>>> 
>>> 1. enum names vs prefixes
>>> enum FOO { FOO_A, FOO_B }; -> enum FOO {A,B}
>> 
>> I actually do number 1 whenever creating C bindings. Because its not
>> really DRY to write: FOO.FOO_A
> 
> alias FOO = int;
> enum { FOO_A, FOO_B };
> 
> Otherwise, it doesn't match the C API.

But then you lose the type-safety of an enum. Why not this:

	enum FOO { FOO_A, FOO_B };
	alias FOO.FOO_A FOO_A;
	alias FOO.FOO_B FOO_B;

?

Overly verbose perhaps.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 10/27/2013 12:11 AM, Michel Fortin wrote:
> On 2013-10-26 14:52:42 +0000, Mike Parker <aldacron@gmail.com> said:
>
>> On 10/26/2013 9:09 PM, Benjamin Thaut wrote:
>>> Am 25.10.2013 15:10, schrieb Lionello Lunesu:
>>>>
>>>> 1. enum names vs prefixes
>>>> enum FOO { FOO_A, FOO_B }; -> enum FOO {A,B}
>>>
>>> I actually do number 1 whenever creating C bindings. Because its not
>>> really DRY to write: FOO.FOO_A
>>
>> alias FOO = int;
>> enum { FOO_A, FOO_B };
>>
>> Otherwise, it doesn't match the C API.
>
> But then you lose the type-safety of an enum. Why not this:
>
>      enum FOO { FOO_A, FOO_B };
>      alias FOO.FOO_A FOO_A;
>      alias FOO.FOO_B FOO_B;
>
> ?
>
> Overly verbose perhaps.
>

When you do it by hand, as I do, this approach can make you cry.

On 10/25/13, 18:22, John Colvin wrote:
> On Friday, 25 October 2013 at 13:26:33 UTC, John Colvin wrote:
>> On Friday, 25 October 2013 at 13:10:05 UTC, Lionello Lunesu wrote:
>>> There's a lot of expressiveness that can be added to D bindings, when
>>> compared to the C or C++ headers, for a particular library:
>>>
>>> 1. enum names vs prefixes
>>> enum FOO { FOO_A, FOO_B }; -> enum FOO {A,B}
>>>
>>> 2. enum vs int parameters (based on a lib's documentation)
>>> void takefoo(int) -> void takefoo(FOO)
>>>
>>> 3. "in" for input buffers (again, based on docs)
>>> int puts(char*) -> puts(in char*)
>>>
>>> 4. "out" or "ref" for output parameters
>>> void getdouble(double*) -> void getdouble(out double value)
>>>
>>> 5. D arrays vs length+pointer pairs
>>> void bar(size_t len, int* ptr) -> void bar(int[] a)
>>>
>>> 6. D array wrappers
>>> void bar(int* ptr, int size) ->
>>> void bar(int[] a) { bar(a.ptr, cast(int)a.length; }
>>>
>>> 6. library specific sized-int typedefs to D natives
>>> png_uint_16 -> short
>>>
>>>
>>> These are some of the more trivial ones, but I'd like to see how
>>> other people go about making bindings. Do you keep as close to C as
>>> possible? Or do you "add value" by using more D style constructs?
>>>
>>> L.
>>
>> I would go for a two stage approach:
>>
>> 1) Write bindings that map as closely as possible to the C API, only
>> adding anything extra by necessity and/or where it is transparent in
>> correct usage.
>
> As an aside, I would suggest that function overloads that take arrays
> instead of pointer + length is normally a harmless addition to an
> otherwise 1:1 set of bindings.

Thanks for the feedback, but your last reasoning could be applied to the other points just as well :)

L.

On 10/25/13, 15:34, Dicebot wrote:
> I think best approach is to have 2-step bindings. First step is pure
> 1-to-1 translation with no D-ification at all. Second step is D wrapper
> that expresses same functionality in more native syntax (probably even
> more type-safe). Step-2 module imports Step-1 module of course.
>
> Benefit of such approach is that you can generate bindings using
> automatic tool when new header version is out without wasting time on
> adjusting those to D style again and again - you only need to change
> step-2 module if there are some breaking API changes.

That's a good point. A "diff" is much more manageable with a 1:1 conversion.

L.

On 10/26/13, 12:54, Jacob Carlborg wrote:
> 2. Slightly D-ify the C bindings. I.e. be able to pass D strings instead
> of C strings

Hadn't even mentioned that one, but yeah, that's one of my favorite overloads!

L.