On Monday, 12 August 2019 at 13:08:17 UTC, Bert wrote:
What I'd like to do is write the business end of apps in D and
use C# for the gui(with possibly wpf hosting a D gui window in
some cases for performance of graphics). I want to leverage D's
meta programming to write efficient oop structures.
Exactly what I'm doing. Client and server backends are written in
D. Binderoo generates the C# <==> D interfaces.
There's a few traps I haven't worked out fully yet. Structs are a
sticking point. I have them byte mapped exactly, but. Well.
Here's an example: std.uuid.UUID
[ Serializable ]
[ StructLayout( LayoutKind.Explicit, Pack = 8 ) ]
public struct UUID
{
public enum Version : int
{
unknown = -1,
timeBased = 1,
dceSecurity = 2,
nameBasedMD5 = 3,
randomNumberBased = 4,
nameBasedSHA1 = 5,
}
//
public enum Variant : int
{
ncs = 0,
rfc4122 = 1,
microsoft = 2,
future = 3,
}
//
//
// Methods
//
public void swap( ref std.uuid.UUID rhs )
{
binderoointernal.FP.std_uuid_UUID_swap3( ref this, ref
rhs );
}
//
public ulong toHash( )
{
return binderoointernal.FP.std_uuid_UUID_toHash4( ref
this );
}
//
public string toString( )
{
return new SliceString(
binderoointernal.FP.std_uuid_UUID_toString5( ref this ) ).Data;
}
//
//
// Properties
//
public std.uuid.UUID.Variant variant
{
get { return binderoointernal.FP.std_uuid_UUID_variant1(
ref this ); }
}
//
public bool empty
{
get { return binderoointernal.FP.std_uuid_UUID_empty0(
ref this ); }
}
//
public std.uuid.UUID.Version uuidVersion
{
get { return
binderoointernal.FP.std_uuid_UUID_uuidVersion2( ref this ); }
}
//
//Ridiculous fixed array preservation code for data of length
16
[ FieldOffset( 0 ) ] private byte var_data_elem0;
[ FieldOffset( 1 ) ] private byte var_data_elem1;
[ FieldOffset( 2 ) ] private byte var_data_elem2;
[ FieldOffset( 3 ) ] private byte var_data_elem3;
[ FieldOffset( 4 ) ] private byte var_data_elem4;
[ FieldOffset( 5 ) ] private byte var_data_elem5;
[ FieldOffset( 6 ) ] private byte var_data_elem6;
[ FieldOffset( 7 ) ] private byte var_data_elem7;
[ FieldOffset( 8 ) ] private byte var_data_elem8;
[ FieldOffset( 9 ) ] private byte var_data_elem9;
[ FieldOffset( 10 ) ] private byte var_data_elem10;
[ FieldOffset( 11 ) ] private byte var_data_elem11;
[ FieldOffset( 12 ) ] private byte var_data_elem12;
[ FieldOffset( 13 ) ] private byte var_data_elem13;
[ FieldOffset( 14 ) ] private byte var_data_elem14;
[ FieldOffset( 15 ) ] private byte var_data_elem15;
//Ridiculous fixed array preservation code for ulongs of
length 2
[ FieldOffset( 0 ) ] private ulong var_ulongs_elem0;
[ FieldOffset( 8 ) ] private ulong var_ulongs_elem1;
//
}
C#'s types and D's don't exactly match (ESPECIALLY if you run on
Windows vs any other platform). If I want to match the C ABI that
D adheres to, I have to go full paranoid and define an explicit
pack.
Then there's things like strings. I've still not come up with a
way that I'm satisfied with to deal with allocated data being
passed between both languages and not being garbage collected.
You could take the "GC pin" route. But I'm not satisfied with
that for parameter passing. There's no guarantees a user will or
won't keep a string on either side of the language divide.
I'm still pondering on that one. I'm taking a convention of
array.dup in my D code whenever assigning a slice in a C# exposed
function. Full solution to be determined.
For it to work well the amount of boilerplate has to be
minimized and the interfacing between D and C# also has to be
minimal.
Absolutely. The original goal of Binderoo was to make C++ and D
interoperation and hot reloading seamless. Since I left Remedy,
that goal has now become to make language barriers irrelevant for
any supported
