Ethan: About your wpf/C# and D integration
Ethan
gooberman at gmail.com
Mon Aug 12 16:58:33 UTC 2019
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 language.
But for my use cases, I've mostly focused on exposing D to C#. I
have not worked on the obverse yet. But I do have my D code
calling C# code through delegates and function pointers. That's
led to some hilarity in C#. Did you know C# will collect locally
defined delegates and marshalled pointers to that delegate during
a thread sleep? Thanks C#. Even D knows how to scan the stack for
managed pointers.
> I'd have to be able to access the D types in C# somehow to
> access the data so it can be visualized. I'm thinking that D
> could emit some type of interface that allows referencing the
> objects in C# as if they were C#, more or less(doesn't have to
> be full blown, but at least fields and basic methods and
> properties).
Classes are actually in a reasonably good state. For my use case,
at least.
In both C# and D, they're reference types where storage is not
defined by the user. Trying to keep binary compatibility between
the two is going to be a nightmare. Solution? The D code
generates properties for publicly accessible variables, and just
binds methods otherwise.
I support inheritance, but as I don't use interfaces myself
(metaprogramming and static branching all the way) there's zero
support for them.
The implementation details is that Binderoo allocates a class in
native code and the pointer gets stored in C#. I don't let the D
GC manage that memory at all, Binderoo allocs/emplaces/destroys
everything itself. All the properties and methods call delegates
I store elsewhere, basically exactly like that code you see in
the UUID example above.
> I'm just not sure how much you've actually achieved in it or
> how well it works. If it's just as much trouble as using D
> directly(I use gtk and it works well for the most part but it's
> a little bit of pain in some ways).
One implementation detail I need to talk about.
I don't bind XAML directly to my D representations.
Binding properties in XAML is weird. You can do it with nullable
properties (ie append a ? to your value type property, now you've
got a nullable property) except for when they don't work. So you
can implement the INotifyPropertyChanged interface and force XAML
bindings to refresh whenever your property changes, except for
when they don't work. So you go brute force and use dependency
properties, which are a ton of boilerplate and copy the value off
somewhere outside of your class instance - but they work 100%
every time.
My D code has a separate function that generates object wrappers
for XAML binding that stores an internal instance of the D class.
Every property gets its own dependency property.
This actually turned out to be an advantage as far as using WPF
is concerned. Because you'll only get the value changed callback
for your dependency property *if* the value actually changes when
your XAML form sets a value. If it's the same value, you don't
get the callback. And since my WPF UI is a frontend for a client,
that means that WPF automatically does the job of working out
when I should send new data to the server for me. The value
changed callbacks invokes the writing API, I set the new values
on my D object, and then the client kicks off the changes to the
server. Server rejects those changes? I force the XAML binding
object to refresh its values and they all get flushed out to the
UI.
The extra object is pretty specific to my use case. It should be
quite alright to generate dependency properties on a D object and
do it that way.
More information about the Digitalmars-d-learn
mailing list