I've gotten a few requests about the force directed graph post that I made several months back.  Seems that this is a popular topic for people trying to find code to do this, and I've been asked several times to post the code.

First, I don't know how robust and scalable this control is, as I was only writing it to learn some WPF control templating.  Also, I modeled the engine off of some code in another open source project that is GPL.  I say modeled as I literally wrote my own off of that code, but because of that it is somewhat similar, so I wonder about distributing my code before I do some checks into licensing.  Until I figure that out, you can get the code that I started with over at the Netron site and do similarly to what I did.  Note that the code in that project supports a lot more functionality, is highly intertwined with WinForms code (not WPF), and that is where I spent most of the time converting things into an engine that only does force directed layout, is seperate from the UI, and of course with a WPF interface.

And, as I mention in this post, I've actually moved on with creating what should be a much more robust force directed graph control using the C++ boost graph library wrapped with C#.  That code is in a really early stage and not worth posting at this point, but given the interest I may very well try to get it better and posted for everyone.  That is free to distribute if that time ever comes.  Unfortunately, it does not work quite as well as the former project at this point as I am still learning how to do the C++ to C# integration.

A few days ago I was doing some searching around the net to try and find if there was any information I hadn't previously found on doing force directed graph layout.  This came up as someone had noticed here on the blog that I had a control that did that.  Unfortunately I don't consider that code to be very robust, so I was looking around to see if I could find a library or some sample code to do it better.

Well, what I came across was a C++ library called Boost (you can find it here).  It's a generic programming library, and consists of quite a few components, but one of them is a graph library that does have classes for force directed graph layout.  So, I downloaded it with hopes of being able to learn some more about how to generate these types of graphs.

Now, I used to be quite the C++ programmer, but have done almost 100% C# since 2000, but I figured I could just jump right back into it.  Well, apparantly not.  Seems the world of C++ has really moved forward into a concept known as generic programming through the use of C++ templates.  This technique goes well beyond what I used to use templates for in C++, and currently use Generics for in C#.  Generic programming as being currently used utilizes a metaprogramming facility from within the host language to generate new semantics into the language.  In a way, this kind of aligns with research I've been doing lately into domain specific languages (specifically DSLs in Ruby).

Don't get me wrong here, as I really love C# (particulary the stuff in 3.0/3.5), and think it has been pushing the model for programming ahead better than anything else, but I had been feeling that it wasn't moving fast enough.  Dynamic languages is one place where I was seeing usefulness (Ruby/IronRuby specifically), also with Domain Specific Lanaguages (both with Ruby, as well as with the Microsoft DSL tools), and now with generic programming, and most importantly with C++.

It really seems to me that C++ is a toolset that must be put back into any programming gods toolset.  I've always missed several features in the C++ language in C#, particularly the ability to pattern match through automatically promote object creation through a chain of constructors (a technique I used a lot to reduce code).  Now with generic programming, combined with libraries such as Boost and the STL, this really may be one of the best ways of getting particular tasks completed the most effectively.

BTW, on the concept of the STL, I've never understood Microsoft's position on container classes.  I was one of the first adopters of using the STL when it came out, but Microsoft's support for it in their C++ compiler was always buggy, so it was always difficult to use in that environment.  But the design of the classes really are the best.  I mean, every time I still code a dictionary in C#, I still mentally think of the much more flexible stl::map class.  C# containers always just felt incomplete compared to the STL.

One thing that I was really surprised at was that the Boost library actually compiled and ran without problems in VS.NET 2008.  Previous experience has shown that this would not be the case (as with the STL).  Kudos to the C++ team for keeping up.

Now this C++ generic programming thing seems to be quite the adventure to learn.  I can tell that there is something very important there, but its quite a mental shift to pick up.  I'm looking into some resources about it and I'll write about my experiences.

Additionally, the integration of C++ in to C#, through one weekend of effort, has been quite challenging (as well as interesting).  It's not possible to use a library like Boost directly in your C# apps (which I have to keep doing), but it is usable in unmanaged C++ within managed C++ (an interesting topic itself), which is then used as components in a C# application.  This involves several interop techniques, but appears to work quite well.  I'll drop some notes on that too as I move forward on this adventure.