Graeme Hill’s Dev Blog

The C++ const keyword is a powerful tool. It basically allows you to pass a pointer or reference that can only be used to call const methods. ie: You can implement a mutable class and then pass an immutable reference to that class (the keyword also does other things, but that’s not what I’m writing about). This defines a much stronger contract. When a function asks for a pointer to an instance of Foobar it can promise that it will not change that object. For example:

#include <string>
#include <iostream>
 
// Here's a piece of a class with one const method and one non-const method
class Person
{
public:
	std::string getName() const { return name; }
	void setName(std::string newName) { name = newName; }
private:
	std::string name;
};
 
// This function asks for a references to a person but promises not to change the object
void doSomethingWithPerson(const Person &person)
{
	std::cout << person.getName(); // <-- this is fine
	person.setName("hello"); // <-- COMPILE ERROR
}
 
int main(int argc, char *argv[])
{
	Person myPerson;
	myPerson.setName("Foobar");
 
	doSomethingWithPerson(myPerson);
 
	return EXIT_SUCCESS;
}

I love code like this. When I call doSomethingWithPerson() I know for sure that it will not change the object (assuming I have properly labelled my const methods). This is an area where I generally think of languages like Java or C# as being superior to C++. We commonly assume that these higher level languages are better at protecting programmers from themselves (or other programmers) but here it is not the case. You can achieve a similar result by creating an immutable class, but what if you do want to change it in other cases? Maybe you want to pass an immutable instance to one function and a mutable instance to another. This can surely be implemented, but it likely involves creating a second class (maybe a read-only subclass) which is kind of a pain. In reality developers often do not bother to create read-only versions of classes where it is warranted, but they will take the time to put const where it is needed.

After a lot of time just working in .NET I have returned to doing some C++ programming on a hobby project. Suddenly I feel dirty when I go back to .NET and start passing objects as function parameters willy nilly without using a const reference. It really is amazing how programming in different languages can change the way you think.

It took me forever to get this right so I thought I’d post my solution. Most of the examples I found were for previous versions of Blender (the API changed a lot in Blender 2.5). The sample scripts I did find never seemed to work and the official documentation seemed to be somewhat insufficient.

The first thing you need to understand is that there are bones, and then there are pose bones. They are completely different objects:

# Get the armature (this technique assumes it is selected)
armature = bpy.context.active_object
 
# Get bone and pose bone data
bones = armature.data.bones
pose_bones = armature.pose.bones

Pose bones contain pose data for the current frame, while regular bone objects store the default state of the bone (ie: as it appears in edit mode). In order to get a pose at a specific frame you actually need to set the frame:

scene = bpy.context.scene
armature = bpy.context.active_object
 
# Loop through every frame in the scene and get bone pose at each one
for frame in range(scene.frame_end + 1):
    scene.frame_set(frame)
    for pose_bone in armature.pose.bones:
        do_something_with_pose_bone(pose_bone)

We can now get each pose bone object at each frame. All that’s left is figuring out how to extract the bone rotation and position info. In my case I assumed that the bone does not move, it only rotates around its pivot point, which is called the “head” of the bone in Blender. Here’s how we get the head location of the bone:

bone = armature.data.bones[0]
head_position = armature.matrix_world * bone.head_local

That’s pretty easy, you just take the local position of the bone and translate it to world coordinates. Rotation gets a little more complicated. Since I set my rotations with quaternions in blender I thought it made sense to just use pose_bone.rotation_quaternion. That expression yielded the exact value that is displayed in the editor while in pose mode so I figured I was good to go. However, on closer inspection, the value returned by rotation_quaternion most definitely does not represent the rotation of that bone relative to its parent. In order to get that value I eventually found this technique:

def get_pose_bone_matrix(pose_bone):
    local_matrix = pose_bone.matrix_channel.to_3x3()
    if pose_bone.parent is None:
        return local_matrix
    else:
        return pose_bone.parent.matrix_channel.to_3x3().inverted() * local_matrix

Note that you can easily convert between matrices and quaternions using the to_quaternion() and to_matrix() methods. The idea here is to get the local matrix and then basically undue the rotation from the parent. Originally I thought I would have to keep going up the tree to the root bone, but apparently not. Going one level up seems to be enough.

I hope this saves someone from ripping their hair out like I did!

In recent memory I have twice tried to write reflection code that seemed totally badass at the time but turned out to be just plain bad. One case involved the use of GetCallingAssembly() and the other involved navigating the stack trace with stackTrace.GetFrame(1). While there is nothing inherently wrong with these functions (ie: they can be used perfectly fine for logging or debugging) you absolutely cannot depend on a specific result due to runtime optimizations by the .NET JIT compiler. For example, imagine A calls B and B calls C. If C runs GetCallingAssembly() then you would expect to get the assembly of B; however, if function B gets inlined in A (which is not uncommon) then technically A is directly calling C, and you will actually get A as a result! In fact, if you check the MSDN documentation they even warn you about this:

If the method that calls the GetCallingAssembly method is expanded inline by the just-in-time (JIT) compiler, or if its caller is expanded inline, the assembly that is returned by GetCallingAssembly may differ unexpectedly.

The documentation for GetExecutingAssembly() has no such warning, but just to be safe I prefer to be explicit with something like this: myObject.GetType().Assembly

I often find that I get so used to using List<T> for my collections that I forget to consider whether it is really the right tool for the job. If the collection is not ordered, and you don’t want duplicates then there are a lot of benefits to using HashSet<T>. For example with List<T> you’ll find yourself writing code like this:

if (!myCollection.Contains(newString))
{
    myCollection.Add(newString);
}

This is a little verbose and it’s also inefficient. Every time you call Contains() the entire collection has to be scanned. With a HashSet<T> set operations are optimized and the code is simpler:

myHashSet.Add(newString);

The other benefit is that you actually enforce the no duplicate rule since adding the same element more than once will have no effect. Here’s what the MSDN documentation says about HashSet<T>:

The HashSet(Of T) class provides high-performance set operations. A set is a collection that contains no duplicate elements, and whose elements are in no particular order.

In practice I am finding that there are actually a lot of scenarios when I really want a set and not a list. So the next time you create a collection, think about whether you can use a HashSet.

Usually it is easy to import a subversion repository into git. You just do this:

mkdir my_project
cd my_project
git svn init svn://repo.url/goes/here
git svn fetch

This will always fetch the repository you specified, but sometimes in svn your project actually depends on multiple repositories (ie: you use external references). The external reference will not be fetched and you will have to manually add it in somehow.

Did you really think it would be that easy?

Properties are supposed to provide encapsulation for your getter and setter logic, but they really don’t enforce it. Here’s what I mean:

private String _title;
 
public String Title
{
    get
    {
        // do custom getter stuff here
        return _title;
    }
    set
    {
        // do custom setter stuff here
        _title = value;
    }
}

The private field _title is the backing store for the property Title. The issue is that I don’t want to manually create this backing store, and I really don’t want it to be available anywhere in the class. I want to force anyone who edits this class to modify the value using the property, not the backing store. You don’t have to create a backing store with a default property like this:

public String Title { get; set; }

This is convenient, but it beats the point entirely. I specifically want to avoid the backing store when I have custom logic in either the getter or the setter. Currently in C# and VB (and every other language I can think of for that matter) there is no way to force the use of the property internally. I think it would be ideal to have an automatic backing store that is only accessible within the getter and setter.

Am I crazy?

A challenging question that programmers are often faced with when chosing a library is whether to go with an open source option or a closed source product that may come with professional support. The answer of course is “it depends” and the quality of each library will often be more important than whether or not it is open source. In the past I have not concerned myself too much with whether or not the source code is available to me because I normally don’t plan on ever touching it. I don’t use an existing library because I want to spend weeks digging through source code and internals, I use them because I don’t want to spend much time on that feature. I want it to just work.

In recent projects I have looked closely at both LINQ to SQL and NHibernate for my ORM needs. Since LINQ to SQL is easy to use and meets my requirements it seemed like a no brainer to use a product from Microsoft over NHibernate since I never planned to edit the NHibernate source. However, a bug that I recently found in LINQ to SQL has made me think differrently (I wrote about the bug here). I don’t blame Microsoft for having a bug in their code since all software has bugs, but when I found out that Microsoft does not plan to fix the issue, I suddenly realized that the team had hit a brick wall. We had already made a big committment to LINQ to SQL. Now there is a bug that Microsoft won’t fix, but they also won’t let anyone else fix it! If NHibernate had been chosen then the worst case scenario is that you have to fix it yourself (though it is likely that someone else will fix it first).

The lesson: proprietary libraries are not the safe option. The only way to ensure bugs will be fixed is if you can fix them yourself.

The title of this article is a pretty obvious statement, but it’s actually pretty easy to forget and it can lead to some painful bugs. Here’s a code snippet whose output may seem surprising:

Module Module1
 
    Sub Main()
        Dim query = 
            From name In {"one", "two", "three"}
            Select New User(name)
 
        Dim x = query.First
        Dim y = query.First
 
        Console.WriteLine(x Is y)
 
        Console.ReadKey()
    End Sub
 
End Module
 
Public Class User
    Public Sub New(ByVal username As String)
        Console.WriteLine("Creating user: " & username)
    End Sub
End Class

At first glance it looks like x and y are the same object, but since query is just a query, not an actual collection, the result will be fetched independently each time you call First. When the code is run, the console output looks like this:

Creating user: one
Creating user: one
False

This shows that the constructor was called twice for the same string, which explains why x and y are actually different objects. In a case like this it is better to put ToList at the end of the query:

        Dim users =
            (From name In {"one", "two", "three"}
             Select New User(name)).ToList()

Bugs like this can be particularly problematic when you pass around an object of type IEnumerable and the programmer assumes that they are dealing with a collection, when they are really dealing with a query. So… watch out!

Up until Visual Studio 2010, simple property definitions were always ridiculously verbose. For example:

    Private _title As String
    Public Property Title() As String
        Get
            Return _title
        End Get
        Set(ByVal value As String)
            _title = value
        End Set
    End Property

That’s 9 lines of code just to make a simple string property. Luckily, in VB 10 we will be able to write these simple properties in one line:

    Public Property Title As String

This is great, but what if things get a little more complicated? Obviously this syntax just uses the default getter and setter, both of which have the same scope. When I write my properties I like avoid using ReadOnly and instead make the setter private so that I can still encapsulate the setting code within the class. With VB 10 you still have to define the property the old way in order to do this:

    Private _title As String
    Public Property Title() As String
        Get
            Return _title
        End Get
        Private Set(ByVal value As String)
            _title = value
        End Set
    End Property

But now it’s back to 9 lines just because I wanted the setter to be private. In C#, programmers have the luxury of writing properties like this:

    public string Title { get; private set; }

Furthermore, neither language allows you to use a default getter and custom setter (or vice versa) probably because it would make it difficult for them both to use the same backing store, but that’s a whole other tangent. Overall, the new abbreviated syntax for properties in VB 10 is great for the simple cases, but you have to revert to the old, verbose method if you want to deviate from the default in even the slightest way.

If you keep the same entity around after it has been deleted and SubmitChanges() is called then you can run into an InvalidOperationException if you try to insert it again.

var data = new DataClasses1DataContext();
var user = new User() { userName = "foo", password = "bar" };
 
data.Users.InsertOnSubmit(user);
data.SubmitChanges();
 
data.Users.DeleteOnSubmit(user);
data.SubmitChanges();
 
data.Users.InsertOnSubmit(user);
data.SubmitChanges();

Here you will actually get an exception on the second InsertOnSubmit() because the data context remembered the entity and will no longer allow you to attach it for some reason. Once an entity has been deleted from a data context it can never go back. To get around this you need to either insert the entity to a different data context or copy the data to a new instance of the same entity class and then insert it. This has been confirmed here.

Note: You are free to call DeleteOnSubmit() and then InsertOnSubmit() all you want as long as you never call SubmitChanges().