On 19 September 2013 02:57, Adam D. Ruppe <destructiona...@gmail.com> wrote:
> On Wednesday, 18 September 2013 at 16:05:00 UTC, Manu wrote: > >> This seems okay at first, but then you realise there are serious problems >> with new (wants to return new memory, I can't hook the new operator?), >> > > There is an override for new, but it is deprecated in d2. > http://dlang.org/memory.html#**newdelete<http://dlang.org/memory.html#newdelete> > > > I kinda hate this. the struct keyword totally gives the user the wrong >> impression, and people have a natural instinct to avoid passing structs >> around by value >> > > ...just don't do that? You don't write "ref Class obj" in D, so just > pretend the struct is a class and do it the same way. > > The only time you'd even need to know it is a struct is if you look at the > source, and there you can write > > struct /* but pretend it is a class! */ whatever { > } > Except those times when you read "struct Thing" in the documentation, or hover over it in the IDE and it says "struct Thing", or when the syntax hilighting makes it go the struct colour. It's still a struct, it's obviously a struct, and that communicates some amount of intent. What you describe is a hack, and I don't want to build the foundation of a performance-oriented library upon a hack. If that's as good as it gets, then there's a deficiency in D here that we need to think about. I also don't have faith in many compilers passing struct's-with-only-a-single-member to functions by that member's type rather than as a struct. Here's how I might do it. Given this simple C test header: > > struct Test; > > struct Test* makeTest(int num); > void addTestRef(struct Test* t); > void killTest(struct Test* t); // i should have called that releaseref lol > int getNumber(struct Test* t); > void setNumber(struct Test* t, int n); > > > > We might use it in D like this: > > > // this represents the struct Test in C, our opaque pointer > // (the disabled stuff is to workaround a minor dmd bug) > struct c_Test { > @disable this(); > @disable this(this); > } > > // and this is our D wrapper > // always pass this by value > struct Test { > // the internal reference > private c_Test* c_ptr; > > // construction can only be done publicly through the static make > method > @disable this(); > private this(c_Test* ptr) { > c_ptr = ptr; > } > > public static Test make(int num) { > return Test(makeTest(num)); > } > > // the alias this lets us call the rest of the binded C functions > with UFCS without manually writing wrappers > c_Test* getCPointer() { return c_ptr; } // it does a property so > you can't assign to the internal pointer > // you CAN break the refcounting with this, but since you have to > specifically ask for the uglier c_Test* to trigger > // this, it is unlikely to happen by accident. > alias getCPointer this; > > // refcount stuff > ~this() { > c_ptr.killTest(); > } > this(this) { > c_ptr.addTestRef(); > } > } > > // you might notice the above is pretty generic, perhaps it could all be a > single template so you don't rewrite it for too many types. > > // and the C function prototypes > extern(C) { > c_Test* makeTest(int num); > void addTestRef(c_Test* t); > void killTest(c_Test* t); > > int getNumber(c_Test* t); > void setNumber(c_Test* t, int n); > } > > // test program > import core.stdc.stdio; > void foo(Test t) { > printf("foo on %d\n", t.getNumber()); > t.setNumber(20); > } > > void main() { > auto t = Test.make(12); > auto t2 = Test.make(24); > > printf("about to call foo\n"); > foo(t); > printf("done calling foo\n"); > > printf("main with t == %d\n", t.getNumber()); > printf("main with t2 == %d\n", t2.getNumber()); > } > > > > > You don't have my c implementation but it isn't special and running the > program produced the following output: > > Test made with number 12 > Test made with number 24 > about to call foo > aref refcount now 2 on Test 12 # refcount increased properly for the > function call > foo on 12 > dtor refcount now 1 on Test 20 # and properly decreased when ending > done calling foo > main with t == 20 # setting the number in foo() correctly did it by > reference > main with t2 == 24 > dtor refcount now 0 on Test 24 # and main is dead, so we release the ref > automatically > Test killed with number 24 # refcount == 0, so C free()'d it > dtor refcount now 0 on Test 20 > Test killed with number 20 > > > > > Using UFCS for the C functions might be a little bit weird, but saves > tediously writing them all out again to forward inside the struct. > Well, this is precisely what I've tried before, but I don't like it. It feels like a hack. Can you make me some promises about the ABI for passing that struct by value across every compiler+architecture? I don't like that it's a struct, it's NOT a struct, it's a handle. There was some discussion about windows HANDLE types recently. I can't remember where I saw it, but I felt like that was quite relevant. It even dealt with the problem of HWND implicitly casting to a HANDLE, and I also have that problem here.
