Starting work on a new native C++ version of Isis2

Dec 2, 2014 at 1:39 PM
I'm starting to port the C# library to native C++ and thought I might see if there are any suggestions that users of the current version of the system would like to make.

As you know, the current C# library can be used from C++/CLI by linking against .NET or Mono, but of course you end up with managed code that does garbage collection whenever it is in the mood to do so, etc. A native C++ implementation of the library would try and preserve the current interfaces to the degree possible while eliminating any dependence on .NET and Mono, would compile down to executable code rather than .NET byte code, and would manage its own memory, so garbage collection would vanish as an overhead.

The main issue I'm seeing is that so much of the Isis2 API is polymorphic and reflection-driven. But I'm exploring some of the tricks that others who have gone down this route for C++ have tried to kind of hack around the very limited C++ type system.

For example, and this is something you folks could chime in on and help me with:

1) Consider an Isis2 call like g.Send(x, y, z). Isis2 reflects on the objects x, y and z to learn their types and uses that type information in various ways -- when it creates messages, to recognize the end of the argument list and the start of the reply lists in a Query, etc. In C++ that type information is not (in general) available within a fully polymorphic, variable-args method like Send (internally, Send just expects a series of things of type Object and uses reflection to deduce the actual types you passed in). So what's the best option for addressing this?

2) When Isis2 does a call to your event handles, like a register message handler, we pass pointers from the library to your code. In C# this works because of managed memory. But in C++ this means that the library will need to allocate objects and then pass them to you. Who should then be responsible for freeing these objects? If you hold onto one of those pointers and then I free the associated object, your pointer could be pointing to anything. If I assume you'll free these objects, then memory leaks are a near certainty because people will forget to do so. The original Isis library had a kind of reference counting scheme it used, and one option is to go down that route again. Another is to provide a method for you to "take ownership" of an object.

3) I do some incredibly elaborate reflection-based upcall magic in the aggregation layer of the system and some moderately fancy reflection-based stuff in the DHT. Unclear whether or not that can be made to work in C++.

So what are your thoughts? I'm genuinely interested in advice and feedback, if anyone is listening!

Ken