Comments on: SWIG and a Miss We recently struggled with some of this at Harmonix. We moved a bunch of our editors over to WPF from MFC, and needed a way to interop with our C++ objects. We went through several revisions, and none of us are really sure if there is a better way, but here's what we basically ended up with: All editor exposed objects add themselves to a bridge module when created or loaded, and remove themselves when destroyed. On the C# side, this creates an object class which is really just an ID and some helper functions. The ID is a System::IntPtr to the memory address of the object on the C++ side. This allows the C# and C++ side to reference the same object. We had an existing C++ class called DataNode, which was a union allowing you to store pointers to objects, ints, pointers to arrays of DataNodes, floats, etc in our system. I wrote a ToCLR and FromCLR function which will convert this data into the c# equivalent data (ints, list, etc). A ton of data in our engine is transferred via DataNodes, so this made it very easy to use the same data in C#. Finally, we wrote interopt code to request data about an object from the C# side, via an ID and returning that data in DataNode form. This uses our C++ property, function, and messaging framework that was already designed for our scripting language and deeply embedded with every object. This allows the C# side to query just about any information about a game object that it would ever need, and we simply add properties or functions for any additional things we need on the C# side. It took us a while to get to this point, but it works fairly well for us, since it leverages much of the system we already have. The thing I love about it is that we aren't replicating the data on the C# side; rather, the C# side just sets/gets the data from the C++ side every time it needs it (lazy). Oh yeah, to make binding work, we marshal change notifications over from the C++ side, so if a property is changed we send it's change notification on the C# side and the WPF stuff all updates. We recently struggled with some of this at Harmonix. We moved a bunch of our editors over to WPF from MFC, and needed a way to interop with our C++ objects. We went through several revisions, and none of us are really sure if there is a better way, but here’s what we basically ended up with:

All editor exposed objects add themselves to a bridge module when created or loaded, and remove themselves when destroyed. On the C# side, this creates an object class which is really just an ID and some helper functions. The ID is a System::IntPtr to the memory address of the object on the C++ side. This allows the C# and C++ side to reference the same object.

We had an existing C++ class called DataNode, which was a union allowing you to store pointers to objects, ints, pointers to arrays of DataNodes, floats, etc in our system. I wrote a ToCLR and FromCLR function which will convert this data into the c# equivalent data (ints, list, etc). A ton of data in our engine is transferred via DataNodes, so this made it very easy to use the same data in C#.

Finally, we wrote interopt code to request data about an object from the C# side, via an ID and returning that data in DataNode form. This uses our C++ property, function, and messaging framework that was already designed for our scripting language and deeply embedded with every object. This allows the C# side to query just about any information about a game object that it would ever need, and we simply add properties or functions for any additional things we need on the C# side.

It took us a while to get to this point, but it works fairly well for us, since it leverages much of the system we already have. The thing I love about it is that we aren’t replicating the data on the C# side; rather, the C# side just sets/gets the data from the C++ side every time it needs it (lazy). Oh yeah, to make binding work, we marshal change notifications over from the C++ side, so if a property is changed we send it’s change notification on the C# side and the WPF stuff all updates.

]]>
By: Alex/2011/05/27/swig-and-a-miss/#comment-4925 Alex Fri, 27 May 2011 13:22:03 +0000 Regarding #7, Nested Types, I recall solving this one once by ensuring that all references in the C++ definition use explicit naming, ie EncompassingClass::InnerClass That said, my only concrete example of this is in a codebase long lost, so I can't be 100% sure. Regarding #7, Nested Types, I recall solving this one once by ensuring that all references in the C++ definition use explicit naming, ie EncompassingClass::InnerClass

That said, my only concrete example of this is in a codebase long lost, so I can’t be 100% sure.

]]>