A simple wrapper for C++ class

Interoperability between a C++ class and a C# object is a huge issue as is obvious by the fact that C++ has a static object structure and C# has a dynamic object structure. So, lots of interoperable wrapper classes and interfaces have to be used to create communication channels for the two different runtimes. Not so anymore with the introduction of the new DLR (Dynamic Language Runtime).

The DLR of the .Net framework provides types, methods, parameters to be dynamically created with the help of IDynamicMetaObjectProvider, DynamicMetaobject and DynamicObject and another type called ExpandoObject to further enhance dynamism in types by allowing you add members to existing members!

The Expando Object is my chief solution provider for enabling communication between C++ and C# classes.

Given a simple class in C++,

#include
#include
using namespace std;
class person
{
public:
string name;
int age;
};

The solution to enable a C# class to access this C++ is be reading this C++ source file and generating an in-memory XML tree so that this C++ class can be dynamically constructed as a C# class in the DLR and if, for example sake, the C# class wants to assign a name and age to the person class, it can simply write out an XML file that will contain the values. This, then, can be consumed by another C++ class by performing an I/O on the XML file.

I use the Expando object to generate an XML file after reading the C++ source file as follows:

The XML tree


<class name="person">
<Members>
<Member name="name" type="string" scope="public"/>
<Member name="age" type="int" scope="public"/>
</Members>
</class>

What is so special about the usage of the ExpandoObject? The special thing is that the code to generate this XML from a C++ file will work with any number of C++ source files and thus a small piece of code in C# can simplify the complex architecture that is otherwise required for making C++ and C# interoperable.

This XML file is then re-constructed as an in-memory source file and compiled.

Of course, there is a lot more and I have not posted the C# code here as there are many other things that need to be done and the reason I posted this was due to my excitement of having finally found the solution that I had proposed some 5 years back when I was working with Quark Media House and where there was a huge code base in C++.

Agile Tour 2010 - Noida Links to photos

Agile Tour 2010 Noida Photos - http://tinyurl.com/35ltoha

Making NUnit 2.5.5+ work with .Net 4.0

It seems that many have found NUnit 2.5.5 not working with DLLs compiled with .net 4.0. NUnit 3.x has been designated to work with .net 4.0; till that time make a modification to the NUnit config file and add this startup element under the main configuration element :

<startup>
<requiredRuntime="v4.0.30319"/>
</startup>

   

BDD + UADD

This is a cool way of satisfying most of the stakeholders in the development process as well as automating, to a large extent, the scenarios and the acceptance criteria of the tester, without burdening the software development process with too many artifacts or overheads.

In fact, you can accomplish both BDD (Business ("B" for Business or Behavior? I will be exploring this in the upcoming Agile NCR 2010) Driven Development) as well as UADD (User Acceptance Driven Development) with the help of Slim without burdening the underlying development model.

The Scenario tables do not do anything by themselves but when combined with Script or Decision tables they help in maintaining a level of automation in the SDLC that help the business analyst understand that his requirements are visibly satisfied. This can be understood as a BDD approach with the acceptance criteria being defined by the "business" in the Scenario table itself. Of course, there is a maturity level and sense of responsibility to be assumed by the "business" in this approach.

The same acceptance criteria can be defined in Decision tables, which will come at a functional/acceptance test phase that can be identified as a UADD approach. In this form, the tester writes the acceptance criteria after the "Dev completed" swimlane is achieved.

More tools like "Trinidad" (for Java developers) ensures that the developer, too, is able to understand how the acceptance tests are working by running the fitnesse tests right from within JUnit!

Of course, ultimately the goal is the same - to deliver working software at the end of a timebox; the only difference is in how you want to drive the software development process. It is just the packaging that is different!