Tag Archives: c++

Building a DSL with Piglet – Extending our DSL

In the last part we created a very basic DSL for use with turtle graphics. Today we’re going to extend the language with more capabilites and learn more about how to use Piglet and also incidentally a bit of compiler construction (nothing scary, I promise).

This is the DSL we ended up with last time:

pendown
move 50
rotate 90
move 50
rotate 90
move 50
rotate 90
move 50
penup
move -10
rotate 90
move 10
pendown
move 30
rotate 90
move 30
rotate 90
move 30
rotate 90
move 30

One obvious thing here is that it would be really nice if we could have variables. We could represent the constants with something else and perform calculations on them. An important thing is to consider the syntax, for a simple DSL we want something that is easy to parse. For this reason we’ll use a var keyword to make variable declarations and require all variables to start with a $. Let’s modify the existing program to include our new language features:

var $size = 50
var $innersize = 30
pendown
move $size
rotate 90
move $size
rotate 90
move $size
rotate 90
move $size
penup
move -10
rotate 90
move 10
pendown
move $innersize
rotate 90
move $innersize
rotate 90
move $innersize
rotate 90
move $innersize

Looking at the new DSL, we note that there is now a new legal statement to make – the var declaration. So we need to extend statement with another rule. The statement list is already pretty long, so we separate it out into another rule:

// Runtime stuff
var variables = new Dictionary<string, int>();

var variableIdentifier = configurator.Expression();
variableIdentifier.ThatMatches("$[A-Za-z0-9]+").AndReturns(f => f.Substring(1));

variableDeclaration.IsMadeUp.By("var")
    .Followed.By(variableIdentifier).As("Name")
    .Followed.By("=")
    .Followed.By<int>().As("InitialValue").WhenFound(f =>
    {
        variables.Add(f.Name, f.InitialValue);
        return null;
    });

Since we want something that matches not a single constant string, we need to make an expression. Expressions are made using the configuration.Expression() method. You give it a regex and you get back an object. You also need to make a function to return a value for the expression. What we want is the variable name without the $ at the start.

To keep track of what variables we have and what values they have, we add them to a dictionary of strings and integers which we then can reference.

We add this new rule to our choices for statementList by adding this to the end:

.Or.By(variableDeclaration)

Note that our rule has just a single component we do not need to add a WhenFound method. It will automatically return the value of the function returned by the single value. Not that we’re using the values returned yet, but we will.

Continuing on, we want to use the variables for the rest of the commands. In order to do that we need to make another rule. Let’s call it expression. For now, a valid expression is either a constant int value, or a variable name. We then use the new rule instead of plain ints for the move and rotate commands. Here’s the full listing that supports the language that we set out to support so far:

// Runtime stuff
var turtle = new Turtle(canvas1);
var variables = new Dictionary<string, int>();

// Parser configurator
var configurator = ParserFactory.Fluent();
var statementList = configurator.Rule();
var statement = configurator.Rule();
var variableDeclaration = configurator.Rule();
var expression = configurator.Rule();

var variableIdentifier = configurator.Expression();
variableIdentifier.ThatMatches("$[A-Za-z0-9]+").AndReturns(f => f.Substring(1));

variableDeclaration.IsMadeUp.By("var")
    .Followed.By(variableIdentifier).As("Name")
    .Followed.By("=")
    .Followed.By<int>().As("InitialValue").WhenFound(f =>
    {
        variables.Add(f.Name, f.InitialValue);
        return null;
    });

expression.IsMadeUp.By<int>()
    .Or.By(variableIdentifier).As("Variable").WhenFound(f => variables[f.Variable]);

statementList.IsMadeUp.ByListOf(statement);
statement.IsMadeUp.By("pendown").WhenFound(f =>
{
    turtle.PenDown = true;
    return null;
})
    .Or.By("penup").WhenFound(f =>
    {
        turtle.PenDown = false;
        return null;
    })
    .Or.By("move").Followed.By(expression).As("Distance").WhenFound(f =>
    {
        turtle.Move(f.Distance);
        return null;
    })
    .Or.By("rotate").Followed.By(expression).As("Angle").WhenFound(f =>
    {
        turtle.Rotate(f.Angle);
        return null;
    })
    .Or.By(variableDeclaration);

A few interesting possibilities here. It’s perfectly acceptable to replace the int for the variable declaration. In fact, it’s a pretty good idea. This enables us to write things like this:

var $foo = 42
var $bar = $foo

What we really want however is to be able to write this:

var $size = 50
var $spacing = 10
var $innersize = $size - $spacing * 2

We’re halfway there already. What is needed is to create some more rules for how an expression can be made. We start simple, we allow only a single addition. Separate what is today an expression into a new rule called term, and make a new rule for additionExpressions.

expression.IsMadeUp.By(additionExpression);

additionExpression.IsMadeUp.By(term).As("First").Followed.By("+").Followed.By(term).As("Second").WhenFound(f => f.First + f.Second)
    .Or.By(term);
term.IsMadeUp.By<int>()
    .Or.By(variableIdentifier).As("Variable").WhenFound(f => variables[f.Variable]);

So, an addition expression is either an add, or a single lone value. This works fine as long as you dont try something like var $a = $b + $c + 100. This is easily fixable by changing the first term into an additionExpression. We are wiring the rule to itself! And like magic we can have as many additions in a row as we’d like. It’s trivial to add a subtraction expression as well, duplicate the rule, and change the operator and the WhenFound function to subtract instead of add (renaming to addSub instead to reflect the new functionality).

addSub.IsMadeUp.By(additionExpression).As("First").Followed.By("+").Followed.By(term).As("Second").WhenFound(f => f.First + f.Second)
                    .Or.By(additionExpression).As("First").Followed.By("-").Followed.By(term).As("Second").WhenFound(f => f.First - f.Second)
                    .Or.By(term);

However, if we add a multiplication and division here things will start to get strange. Everything will be evaluated left to right, so when writing var $a = 2 + 3 * 10 $a will have the value 60 instead of the expected 32. In order to solve this we need to redefine term. A term will now be a multiplication or division expression or a single factor that is a constant. We also wire this rule to itself like the addition rule so we can do many multiplications in a row. The expression grammar now looks like this:

expression.IsMadeUp.By(addSub);

addSub.IsMadeUp.By(addSub).As("First").Followed.By("+").Followed.By(mulDiv).As("Second").WhenFound(f => f.First + f.Second)
    .Or.By(addSub).As("First").Followed.By("-").Followed.By(mulDiv).As("Second").WhenFound(f => f.First - f.Second)
    .Or.By(mulDiv);

mulDiv.IsMadeUp.By(mulDiv).As("First").Followed.By("*").Followed.By(factor).As("Second").WhenFound(f => f.First * f.Second)
    .Or.By(mulDiv).As("First").Followed.By("/").Followed.By(factor).As("Second").WhenFound(f => f.First / f.Second)
    .Or.By(factor);

factor.IsMadeUp.By<int>()
    .Or.By(variableIdentifier).As("Variable").WhenFound(f => variables[f.Variable]);

As the final thing for today, let’s add support for parenthesis. They go in the factor rule. So, a factor can be an entire expression wrapped in parenthesis. It’s almost a thing of magic. We wire the entire last rule back up to the start.

factor.IsMadeUp.By<int>()
    .Or.By(variableIdentifier).As("Variable").WhenFound(f => variables[f.Variable])
    .Or.By("(").Followed.By(expression).As("Expression").Followed.By(")").WhenFound(f => f.Expression);

This is where we’ll end for this part. We have a fully functional expression parser. You can use expressions for all the commands that previously only took integer values, and you can assign values to variables. A few things for the adventurous to try:

  • Add variable assignment. Make set $foo = 1+3*$bar a legal, working piece of code
  • Add support for the modulus operator
  • Add support for unary minus. var $foo = -$barM work. This is a bit tricky, and don’t be afraid if you get some scary exceptions from Piglet

Next time, we’ll make the DSL a bit more fun. We’ll add some basic flow control! Code on github is updated with the latest version

Advertisements
Tagged , , ,

Using Piglet to create a DSL – Setting the stage for turtles

Piglet has quite a few uses, and a case where it shines in particular is in the area of domain specific languages. So, in order to compliment the admittedly scarce tutorials on how to actually use Piglet, I intend to write a short little series on how to make a domain specific language using Piglet. Let’s get straight to it.

Enter the Turtle

I’m going to go for a classic educational DSL here, Turtle graphics. Because everyone like turtles, right? Basically, it’s a way of drawing graphics that could be imagined as if you had a (very obedient) turtle with a paintbrush attached to the back of it’s shell. Masterfully trained, it responds to three commands:

  • Put the brush up or down
  • Move forward or backward a certain number of steps
  • Rotate a certain number of degrees

I have made a little WPF application that implements this behaviour. Eschewing all the WPF junk, here’s the turtle itself:

    public class Turtle
    {
        private readonly Canvas canvas;
        private double angle;
        private double x;
        private double y;

        public Turtle(Canvas canvas)
        {
            this.canvas = canvas;
            x = canvas.ActualWidth/2;
            y = canvas.ActualHeight/2;
        }

        public bool PenDown { get; set; }

        public void Move(double distance)
        {
            var oldX = x;
            var oldY = y;

            double rads = angle/360.0*Math.PI*2.0;
            x += Math.Sin(rads)*distance;
            y += Math.Cos(rads)*distance;

            if (PenDown)
            {
                canvas.Children.Add(new Line { X1 = oldX, Y1 = oldY, X2 = x, Y2 = y, Stroke = new SolidColorBrush(Color.FromRgb(0, 0, 0))});
            }
        }

        public void Rotate(float a)
        {
            angle += a;
        }
    }

Nothing fancy, unless you’ve forgotten all about basic trigonometry. It takes a canvas and when moving it leaves trails if the pen is set to down. Using the turtle is straightforward. This program draws a twenty-sided polygon:

var turtle = new Turtle(canvas);          
turtle.Rotate(90);

turtle.PenDown = true;

for (int i = 0; i < 20; ++i)
{
   turtle.Rotate(360/20);
   turtle.Move(20);
}

It’s fun drawing with the turtle, but cumbersome since you’d have to recompile every time you want to change the shape. What we would really want is to describe it in a structured way using text. Sort of like a mini-programming language. LOGO would be the classic for turtle programming, but I feel it would be more fun to make our own little language for this.

Turtleese

When making a DSL or full blown language, in any tool, it’s usually easiest to start small and work your way up. To get the ball rolling, or turtle walking, let’s make a language that contains only the basic commands understood by the turtle. A sample piece of this rudimentary turtleese looks like this:

pendown
move 50
rotate 90
move 50
rotate 90
move 50
rotate 90
move 50
penup
move -10
rotate 90
move 10
pendown
move 30
rotate 90
move 30
rotate 90
move 30
rotate 90
move 30

This program should make the turtle draw two concentric squares, 10 units apart. It’s really verbose, but it’s a start that we can improve on. If we look at the structure of the program, we can see that this is made up of list of statements. This is the key to formulate a grammar for parsing the language. Piglet gives us two options for configuring a parser, a fluent and a more technical interface. I’ll use the fluent interface for this series, maybe in the end provide an equivalent grammar in the technical interface. In the end, it’ll serve to deepen the knowledge of how grammars actually work, though you should have a pretty good idea when we actually get there.

Here’s the entire thing:

var turtle = new Turtle(canvas1);

var configurator = ParserFactory.Fluent();
var statementList = configurator.Rule();
var statement = configurator.Rule();

statementList.IsMadeUp.ByListOf(statement);
statement.IsMadeUp.By("pendown").WhenFound(f =>
    {
        turtle.PenDown = true;
        return null;
    })
    .Or.By("penup").WhenFound(f =>
    {
        turtle.PenDown = false;
        return null;
    })
    .Or.By("move").Followed.By<int>().As("Distance").WhenFound(f =>
    {
        turtle.Move(f.Distance);
        return null;
    })
    .Or.By("rotate").Followed.By<int>().As("Angle").WhenFound(f =>
    {
        turtle.Rotate(f.Angle);
        return null;
    });
var parser = configurator.CreateParser();
parser.Parse(code.Text);

Going through it line by line. First we make a configurator object. This is the object that we’ll use to make the parser. Then we make two rules, statementList and statement. A thing of huge importance here. The order of declaring these is vitally important. You see, if you’d make this in the wrong order it would just try to find a single statement. A parser constructed by Piglet must be able to parse everything you give it down to a single rule. For now, the single rule is the statement list. Usually it’s something like “program” for a programming language or translation unit or something to that effect.

Moving on, we declare that a statementList unsurprisingly is made up by a list of statement. This is a reference to another rule.

A statement is declared as one of the four commands that the turtle understands. Following each possibility there is a lambda that gets executed when the parser has recognized that a rule is to be applied. For now we make the turtle do the same thing as the command says. There is a need to return something from the parse function, we ignore that for now and return null. Later on we’ll revisit this and find out why you want to return things from rules.

The move and rotate are interesting, since they have a parameter which is an integer value. We’ll need to find out the value of this parameter. In Piglet, this requires you to give the parameter a name. This name then becomes accessible on the dynamic object that is the input to the WhenFound function. Integers are simple types, so Piglet has a built-in function for recognizing them.

Calling parser.Parse with the code causes to the turtle to do what you wanted it to. The program also gives some helpful hints for when you’ve confused our poor reptilian friend, you get this functionality for free when using Piglet.

The full source code for this tutorial is found on GitHub: TurtlePig. Feel free to fork and mess about with it. The same repo will be updated once this tutorial continues, so you might find a slightly different version. I’ll figure a way to keep all versions accessible.

Next time, we’ll take a look at making this language a lot more capable – step by step.

Tagged , , ,

Fun with Moq: Dynamic mocking

Run time mocking

Sometimes it’s useful to be able to create a Mock object without the type being known at compile time. Normally when using Moq you create a Mock object using this syntax:

var mock = new Mock<IMyInterface>().Object;

But what if IMyInterface is not known at compile time? What you would like would be to do this var mock = new Mock(myType).Object and receive the mocked object back. Turns out this method does not exists, but it’s possible to get around this using the magic of reflection!

public static object DynamicMock(Type type)
{
   var mock = typeof(Mock<>).MakeGenericType(type).GetConstructor(Type.EmptyTypes).Invoke(new object[] { });
   return mock.GetType().GetProperties().Single(f => f.Name == "Object" && f.PropertyType == type).GetValue(mock, new object[] {});
}

This piece of code will return to you a mock that implements the interface type you specify and return it as an object. This could then be used for various fun stuff to automate the unit testing of certain things.

Dynamic parameter checking

Seen this code before?

public class MyConcreteClass 
{
   private readonly IDependency1 _a;
   private readonly IDependency2 _b;
   private readonly IDependency1 _c;
   private readonly IDependency1 _d

   public MyConcreteClass(IDependency1 a, IDependency2 b, IDependency1 c, IDependency1 d)
   {
     if (a == null) throw new ArgumentNullException("a");
     if (b == null) throw new ArgumentNullException("b");
     if (c == null) throw new ArgumentNullException("c");
     if (d == null) throw new ArgumentNullException("d");

     _a = a;
     _b = b;
     _c = c;
     _d = d;
   }
}

It’s great to cast all those ArgumentNullExceptions to check the value, but testing this is a complete pain, since you’d need four separate test cases for each parameter to verify that the correct exception is being thrown. With dynamic mocking and some reflection this can be totally automated for classes that only take interfaces as parameters – which in a heavily dependency injected application is pretty much all of them.

All you need to test this scenario is a single call to NullParameterCheck<MyConcreteClass>() and this method somewhere in your testing code.

public static void NullParameterCheck<T>()
{
	var constructor = typeof(T).GetConstructors().Single();

	Assert.IsFalse(constructor.GetParameters().Any(f => !f.ParameterType.IsInterface), "All parameters must be interfaces in order to use this helper");

	for (int i = 0; i< constructor.GetParameters().Length; ++i)
	{
		var paramName = constructor.GetParameters()[i].Name;
		int i1 = i;
		var args = constructor.GetParameters().Select((p, ix) => ix == i1
			? null
			: DynamicMock(p.ParameterType));
		try
		{
			constructor.Invoke(args.ToArray());
			Assert.Fail("No exception for parameter null {0}", paramName);
		}
		catch (TargetInvocationException e)
		{
			Assert.IsTrue(e.InnerException is ArgumentNullException);
			Assert.AreEqual(paramName, ((ArgumentNullException)e.InnerException).ParamName);
		}
	}
}

This code will loop around each parameter, replacing one of them with null in turn to verify that each interface parameter will generate the corresponding ArgumentNullException

Happy mocking!

Tagged , , , ,

Introducing Piglet

This is an introductory post for my latest creation, Piglet the friendly parsing and lexing tool. As so much software Piglet is written out of both a sense of satisfaction in solving a difficult problem, and seeing a void where my piece of software might be useful to someone. Piglet is open sourced using the MIT license. This post is intended to compliment the readme on github to form a better picture of why I have written this library and how it can be used.

Why another parser generator?!

Because the other parser generators are too big for easy tasks, and harder to integrate into a project. They are also highly technical and hard to understand for someone who isn’t genuinely interested in old-school comp.sci.

The purpose is for you to have a tool at hand for parsing tasks that are smaller than full blown language construction efforts. Piglet tries to bridge the gap between (ab)using regular expressions and going in guns blazing with a large parsing toolset. It is not going to replace ANTLR or any of those tools, though you certainly can parse larger grammars with Piglet. This is the tool to use if you want a low-treshold, easy to use tool for any context free data.

Code based configuration

Piglet is, in sharp contrast to most other generators configurable in code. You create your parser and use it as naturally as you configure any other object. It has about the same functionality as the yacc/bison family of tools and generates similar parsers. This is an important point because if your parser is configured using a separate input file or even a completely separate tool you are always going to have a distance between the running code and the parser. The parser generators also sometimes generate fairly incomprehensible code. If you have a small parsing task, are you really going to use a generator or are you going to roll your own parser?

There are some tradeoffs in this strategy. Obviously the parser generation is going to be done at runtimes. However, the parsers are reentrant to the construction should only need to be done once. It also enables you to be able to use lambdas as actions when rules are followed, which also means that Piglet can construct type-safe parsers!

Ease of use

Unfortunately parsing is a bit complex and it’s usually required to know a bit about context free grammars to be able to construct a parser. Piglet tries to get around this problem by introducing a fluent configuration interface.

It’s easier to show it straight up. This is a full blown JSON parser. The only thing missing here is really only details such as the ability to write 0x notation for hexadecimal and exponent notation for numbers. There rest is all there.

// Create a configuration object. This object generates all the configuration needed for the parser.
var config = ParserFactory.Fluent();

// Create rules. The first rule is the MAIN rule, the rule that everything must be able
// to condense down to. For JSON this is a single object, since a JSON string is always
// just one object.
var jsonObject = config.Rule();

// Used to represent an element of an object
// which is something like "elementname" : some_value
var jsonElement = config.Rule();

// This represents a value of a json element
var jsonValue = config.Rule();

// This represents an array of values
var jsonArray = config.Rule();

// Now we declare what a jsonObject is made up of
// Literals are found in quotes. Interesting parts that we are interested 
// in are named using the As clause, which makes them accessible in the 
// .WhenFound. The result of WhenFound is returned to the caller.
jsonObject.IsMadeUp.By("{")
		  .Followed.ByListOf<JsonElement>(jsonElement).As("ElementList").ThatIs.SeparatedBy(",").Optional
		  .Followed.By("}")
	.WhenFound( o => new JsonObject { Elements = o.ElementList } );

// Declares what an element is made up of. Note that the rule above uses the
// jsonElement before what it is made of is declared. This is a crucial part
// of parsing. This bit has two interesting named pieces "Name" and "Value".
// Since each bit has a value, this gets assigned to the o parameter to the WhenFound lambda.
jsonElement.IsMadeUp.By(config.QuotedString).As("Name")
		   .Followed.By(":")
		   .Followed.By(jsonValue).As("Value")
	.WhenFound( o => new JsonElement { Name = o.Name, Value = o.Value } );

// A jsonValue has several interpretations, separated by Or clauses.
// Predefined parsing is found for simple types. Note the recursive use
// of jsonObject, values can be full objects themselves! There is no need
// for .WhenFound clauses for single part rules, they
// will always return the value of the single part.
jsonValue.IsMadeUp.By(config.QuotedString)
	.Or.By<int>()
	.Or.By<double>()
	.Or.By(jsonObject)
	.Or.By(jsonArray)
	.Or.By<bool>()
	.Or.By("null").WhenFound(o => null); // Need to specify, since the default will return the string "null"

// This rule could have been merged into the jsonValue rule, as its 
// own .Or.By clause. It's separated for readability only.
jsonArray.IsMadeUp.By("[")
		 .Followed.ByListOf(jsonValue).As("Values").ThatIs.SeparatedBy(",").Optional
		 .Followed.By("]")
	   .WhenFound(o => o.Values);

// When the configuratin is completed - create the parser!
// If the parser creation is unsuccessful, this throws the
// friendliest exception possible to help you find the issue.
var parser = config.CreateParser();

// Here is how you use it!
var jObject = (JsonObject)parser.Parse(
	@"{ 
		 ""Property1"":""va\""lue"", 
		 ""IntegerProperty"" : 1234, 
		 ""array"":[1,2,3,4,5],
		 ""another_object"" : {
			""another_property"":13.37
		 },
		 ""empty_object"" : {
			
		 }
	}");

There is also a less verbose technical interface, which right now includes more functions than the fluent one does. In the interest of brevity in this post I’m not going to describe it in detail. The features that currently only exists in the tech interface are context dependent precedence, token precedence, panic mode error recovery and type specific parser generation (the fluent parsers will all generate an object as an end result). These should all be upcoming features in further versions for the fluent interface.

The fluent configuration interface is right now in a working state, but can certainly use more functions! Common tasks should be easy to accomplish while harder tasks may require you to fall back on the technical configuration. As an exciting preview of things to come, I’m currently working on an embedded domain specific language generator (made using Piglet) called Snout, which when finished should help the maintainability of the fluent interface.

Piglet is totally dependency free, and written in C# 4. The code is well commented and understandable. If you are looking for code that reasonably explains the parser generation algorithm, Piglet is a sensible choice.

In technical terms, Piglet generates LALR(1) parsers – mainly because it’s an easier way of expressing your grammar since you do not require left factoring which is a pretty difficult concept to explain.

More examples

I’ve written a Demo project that is available in the main github repository which contains a few demos. The unit tests for Piglet are also quite extensive and are suitable for learning. I’m hoping to find more time to write a detailed tutorial on how to go from a given format into a complete parser. Suggestions for tutorials and articles are most welcome.

Getting your hands on it

Piglet lives on GitHub if you want the source code and demos. It also lives on NuGet if you just want the binaries.

Contributing

You are most welcome, regardless of skill level. There’s lots of stuff to do! Or just fork it and go to town on your own. I would be flattered if you did.

And if you can’t program, Piglet could use a logo. I’m thinking a piglet would make an appropriate one 🙂

Tagged , , ,

Hosting a WPF control inside a MFC window and making the keyboard work

It’s quite possible to host a brand new shiny WPF control inside your smelly old MFC or even Win32 windows. It’s not particularly hard to do so, but you will need to do a few obscure things to make this work. Also, the intellisense that VS provides isn’t operational when working with C++/CLI. So you’ll pretty much have to know what you’re doing.

Similar code such as this can be found, but they often gloss over the details, such as how to deal with feeding the keyboard events to the child window, and how to make sure that the child window will receive tab events. I’ve included this as well, since you’ll probably want those things when integrating your new component.

First off, in your MFC project you’ll need to turn on support for common language runtime (the /clr flag) and you need to set the CLR-tread attribute to STA-thread in the project which ultimately hosts your .exe file. If you don’t do the STA-thread it will crash horribly and it will not be obvious why it has done so. In fact, the only hint is that it seems to crash even before it has a chance to be able to do so. That’s because the default setting is to handle the windows with multiple threads, something which WPF chokes on. The setting is found under Linker->Advanced.

For the sake of discussion lets say you have a dialog which extends the MFC class CDialog. You want to replace the contents of the window with a WPF control. First there is a few things that needs to be added, namely two references that needs to be kept in the dialog to keep the garbage collector from raining on our parade. In the header add two gcroot members:

gcroot m_hwndSource;
gcroot m_wpfControl;

Now to the more interesting bits, how to actually create an area for the WPF control to live in. What you actually need to do is to create something called a HwndSource. This object is a ‘real’ windows window and as such can receive windows messages and are actually understood by the windows system. A fundamental difference between WPF and Winforms/MFC/Win32 is that WPF does not have a HWND for every component that you create. It will only have one outer window and nothing more. This outer window is not created by itself, instead we need to provide such a window for WPF to live in. In some suitable place like the handler for WM_CREATE in your CDialog add this.

System::Windows::Interop::HwndSourceParameters^ sourceParams = gcnew System::Windows::Interop::HwndSourceParameters("MyWpfSourceWnd");
// This sets the position within the parent window
sourceParams->PositionX = 0;
sourceParams->PositionY = 0;
sourceParams->ParentWindow = System::IntPtr(this->GetSafeHwnd());
sourceParams->WindowStyle = WS_VISIBLE | WS_CHILD;

System::Windows::Interop::HwndSource^ source = gcnew System::Windows::Interop::HwndSource(*sourceParams);
MyWpfControl^ wpfControl = gcnew MyWpfControl();

// This creates sets the root visual of the interop component to out user control.
// As a sidenote, THIS is where it crashes if you have forgotten to set STA-thread.
source->RootVisual = wpfControl;

// Adds a keyboard hook!
source->AddHook(gcnew System::Windows::Interop::HwndSourceHook(ChildHwndSourceHook));

// This is the HWND of the interop component, should you choose to save it.
m_wpfChild = (HWND)source->Handle.ToPointer();
   
// This is important! If you do not save these the garbage collector eats them up!!
m_hwndSource = source;
m_wpfControl = wpfControl;

You might have noticed that we also added a hook to the window. This is needed, since if we do not do this your WPF control is never going to receive any keyboard events. The mouse however still works. This is a simple function outlined below:

System::IntPtr ChildHwndSourceHook(
    System::IntPtr /*hwnd*/, int msg,
    System::IntPtr /*wParam*/, System::IntPtr /*lParam*/, bool% handled)
{
    if (msg == WM_GETDLGCODE)
    {
        handled = true;
        // WANTCHARS = input boxes work
        // WANTTAB = tab order works
        // WANTALLKEYS = Enter key will work
        return System::IntPtr(DLGC_WANTCHARS | DLGC_WANTTAB |DLGC_WANTALLKEYS);
    }
    return System::IntPtr(0);
}

This is pretty much all you need to do. Note that there is nothing strange at ALL with the WPF usercontrol. No modifications needed, which also means that you can insert ANY of the cool WPF controls into your MFC application. Also, should you be stuck in Win32 country this works just as well, you just need to provide the parent HWND in another way than this->GetSafeHwnd().

Now go out and create your frankensteinian interop apps to terrorize the neighborhood.

Tagged , , ,

Why you should use prefix increments instead of postfix

This is a pet peeve of mine, so bear with me. I really don’t like this code (curly brace language of your choice, but lets say it’s C#):

for (int i = 0; i < 10; i++)
{
   // Do stuff
}

I specifically do not like i++. If you don’t have a really good reason you should be writing ++i in almost every case. Even when it doesn’t matter, like in the example above, simply because it’s good style to do so.

The result in the loop above is exactly the same if it’s written like this:

for (int i = 0; i < 10; ++i)
{
   // Do stuff
}

So why does it matter? Because sooner or later it will bite you in the ass. You see i++ has the connotation that the l-value of any expression that uses it is the value before it was incremented. Which means that a copy must be made. Sure, the compiler probably optimizes this away, but what if this was an operator overloaded object?

Take a look at this, admittedly stupid but possible, object

public class Overloaded
    {
        private ExpensiveObjectToManipulate junk;

        static public Overloaded operator ++(Overloaded o)
        {
            o.junk.Increase();
            return o;
        }
    }

You see C# only provides one overload method for ++. In glorious C++ you get to overload it twice, in which case you also get the great opportunity to also mess up the semantics of the action. Or change the return type or other generally retarded actions C++ allows. But I digress.

So, C# gives you both prefix and postfix increment for an overload. Prefix does what you think it does. Postfix does not. Postfix will make a copy of the object, assign it to whatever is supposed to be the target of the expression then it will perform the operation on the ExpensiveObjectToManipulate. Now think about if you are using the Overloaded object in a loop. And ExpensiveObjectToManipulate is also expensive as hell to copy. It might be copied by value?

Do you trust your compiler to optimize it away?

Do you trust your vendor of stupid overloaded objects to not have different side effect from the copying?

This might not be a big problem in C# where this sort of operator overloading thankfully is rare, but if you ever get to the wonderful world of C++ you’re going to see this. There is no reason on this earth to use postfix operator with it’s inherent complications in so many cases.

var i = new Overloaded();  // Using fun object for making a point.
foreach (var x in collectionOfX)
{
   // Do stuff with x
   x.DoStuff();
   // increase the counter
   i++; // Why, oh gods, why?!?
} 

There is no reason to use the postfix! Yet I’m willing to bet that many of you are doing it. Same goes for every for loop. So let’s do the safe and optimized thing and use our friend the prefix operator every time you don’t mean to copy things.

Tagged , ,

Finding memory corruption bugs

If you’ve never programmed in C/C++ or any of those languages that require manual memory management or pointers chances are you won’t know the absolute horror that is finding these sorts of bugs. They are evil incarnate. One seemingly harmless pointer is left dangling after the object it pointed to has been deleted. But the pointer isn’t null. Oh no, it’s still pointing out into the void, ready to write bogus data into whatever’s there. Your application will crash, intermittently and sometimes only in production code. Bonus points if it doesn’t happen if the debugger is attached.

These sorts of bugs are extremely hard to find, especially if the codebase is large/old. Recently I came across one of these, which had been causing havoc for quite some time, and set upon the task of fixing it.

There’s a few ways to go about this, you could swap out the memory manager for something of your own design and hope you can find it. You can scale down the code while having the bug still reproduceable in the hope of finding the bug by noticing when it went away and deducing that it must have been in that code you just deleted.

Or try to understand it it more detail. A duo of tools have always done it for me: The memory view in Visual studio and the application verifier.


The app verifier is a magic piece of software that somehow attaches into the executable when running and will cause breakpoints if you mangle memory. I don’t know how it does it, but it does. Download it here. It’s easy enough to use, you add the executable in application verifier, check that it should verify application memory handling and then run it, either normally or through a debugger. Application verifier should stop the execution dead in it tracks much closer to the actual cause than what you get if you just run it.

As an example, in my latest case without the verifier the app crashed deep within Win32 when opening a window. With the verifier, it crashed in our own code – and much more reliably. Once you get it to this state, open the disassembly. Yes, the disassembly. You’ll have to go back one or two steps to get into your own code instead of the verifier inserted code. There, try to see what memory access has offended the verifier. You probably have something like a DWORD ptr that is being dereferenced. Check that memory address in the memory view.

The memory view, besides its best feature of looking like the matrix if you use green on black fonts is quite useful. You’re to identify if you are: writing to uninitialized memory, double-freeing a pointer or overrunning a buffer. Sometimes there are sentinel bytes, especially in the memory managers debug mode, which famously in win32 maps both 0xDEADBEEF and 0xBAADF00D to various states of the debug heap. Sometimes you can see strings which gives you an indication as to where in the code you are.

Either way, you should be much closer to the problem now. In my case, it was an unhandled realloc return which in previous memory management implementations never moved the buffer, but now it did.

Application verifier probably won’t give you the exact line of offending code, but it’ll get you a whole lot closer!

Tagged , , ,