On 9/18/13, Manu <turkeyman@gmail.com> wrote:
> And in D:
>
>   struct Thing;
>   extern (C) Thing* MakeThing();
>
> The question is, does this suck?
> D currently can't allocate an array of Thing*'s for some weird reason.

This is just a current bug that will be fixed. As a workaround you can use this:

struct Thing
{
    @disable this();
    @disable this(this);
}

This will ensure "Thing" will never be copied by value, and you can only use it with a pointer.

On 19 September 2013 02:14, Andrej Mitrovic <andrej.mitrovich@gmail.com>wrote:

> On 9/18/13, Manu <turkeyman@gmail.com> wrote:
> > And in D:
> >
> >   struct Thing;
> >   extern (C) Thing* MakeThing();
> >
> > The question is, does this suck?
> > D currently can't allocate an array of Thing*'s for some weird reason.
>
> This is just a current bug that will be fixed. As a workaround you can use this:
>
> struct Thing
> {
>     @disable this();
>     @disable this(this);
> }
>
> This will ensure "Thing" will never be copied by value, and you can only use it with a pointer.
>

But since I'm always dealing with a pointer rather than a real type, I can't implement logic to inc/dec the ref-count on assignment. And how do I handle destruction/garbage collection?

On 9/18/13, Manu <turkeyman@gmail.com> wrote:
> But since I'm always dealing with a pointer rather than a real type, I can't implement logic to inc/dec the ref-count on assignment. And how do I handle destruction/garbage collection?

Ah I see, well you could try using RefCounted from std.typecons.

For some usage examples you may want to look at how CairoD uses it. It
exposes D classes and some D structs in the D API which use reference
counting:
https://github.com/jpf91/cairoD

Johannes also did a nice job documenting how memory management is dealt with for interfacing with cairo, so this page might be helpful: https://github.com/jpf91/cairoD/wiki/Memory-Management

Here's an example of a typical C API that's begging to be wrapped up all
nice:
http://fujiengine.org/docs/group___m_f_material.html

And it's counterpart: https://github.com/TurkeyMan/fuji/blob/master/dist/include/d2/fuji/material.d You can see some initial experiments I toyed with down the bottom. Abusing the class syntax, and implementing a range interface for the material parameters, but this sucks in a variety of ways...


On 19 September 2013 02:19, Manu <turkeyman@gmail.com> wrote:

> On 19 September 2013 02:14, Andrej Mitrovic <andrej.mitrovich@gmail.com>wrote:
>
>> On 9/18/13, Manu <turkeyman@gmail.com> wrote:
>> > And in D:
>> >
>> >   struct Thing;
>> >   extern (C) Thing* MakeThing();
>> >
>> > The question is, does this suck?
>> > D currently can't allocate an array of Thing*'s for some weird reason.
>>
>> This is just a current bug that will be fixed. As a workaround you can use this:
>>
>> struct Thing
>> {
>>     @disable this();
>>     @disable this(this);
>> }
>>
>> This will ensure "Thing" will never be copied by value, and you can only use it with a pointer.
>>
>
> But since I'm always dealing with a pointer rather than a real type, I can't implement logic to inc/dec the ref-count on assignment. And how do I handle destruction/garbage collection?
>

On 9/18/13, Manu <turkeyman@gmail.com> wrote:
> And it's counterpart: https://github.com/TurkeyMan/fuji/blob/master/dist/include/d2/fuji/material.d

I think those pointers in the MFMaterialCallbacks struct should likely
be marked extern(C).

On 19 September 2013 02:38, Andrej Mitrovic <andrej.mitrovich@gmail.com>wrote:

> On 9/18/13, Manu <turkeyman@gmail.com> wrote:
> > And it's counterpart:
> >
> https://github.com/TurkeyMan/fuji/blob/master/dist/include/d2/fuji/material.d
>
> I think those pointers in the MFMaterialCallbacks struct should likely
> be marked extern(C).
>

Good catch! ;)
But ideally I intend to wrap this all up, and present something that's
actually kinda nice. There's a few angles of attack though.

Am Wed, 18 Sep 2013 18:23:37 +0200
schrieb Andrej Mitrovic <andrej.mitrovich@gmail.com>:

> On 9/18/13, Manu <turkeyman@gmail.com> wrote:
> > But since I'm always dealing with a pointer rather than a real type, I can't implement logic to inc/dec the ref-count on assignment. And how do I handle destruction/garbage collection?
> 
> Ah I see, well you could try using RefCounted from std.typecons.
> 
> For some usage examples you may want to look at how CairoD uses it. It
> exposes D classes and some D structs in the D API which use reference
> counting:
> https://github.com/jpf91/cairoD
> 
> Johannes also did a nice job documenting how memory management is dealt with for interfacing with cairo, so this page might be helpful: https://github.com/jpf91/cairoD/wiki/Memory-Management

Another project which I really should get back to at some point. Note that this code is kinda old now and I think some bugs in phobos RefCounted were fixed since then.

On 19 September 2013 02:23, Andrej Mitrovic <andrej.mitrovich@gmail.com>wrote:

> On 9/18/13, Manu <turkeyman@gmail.com> wrote:
> > But since I'm always dealing with a pointer rather than a real type, I can't implement logic to inc/dec the ref-count on assignment. And how do
> I
> > handle destruction/garbage collection?
>
> Ah I see, well you could try using RefCounted from std.typecons.
>

I don't see how RefCounted does the job. It wants to allocate for me, and offers no customisation of the inc/def-ref functions.