For the last two posts, a spend half the day researching Ruby weirdness instead, quite “unproductively” instead of hacking in a solution for my original problem.
After posting the two entries, I went back to my code, and was able to make the unit tests pass by just deleting four characters…
If you’d like to see the exported functions of an win32 dll, call
dumpbin.exe -exports mydll.dll from the command line.
I had some fun with the Visual Studio debugger today, and actually learnt a few new tricks (even though I’m aware this may be an old hat to some
The problem: I had an object which contained an invalid pointer, and crashed the application. Ups. I could see that the object started out fine, but somewhere along the way said pointer was modified to point to nowhere. I had no idea where the pointer was modified, however.
So what I really wanted to do was my program to break whenever that pointer was touched.
A recent blog entry by Psycho brought an article about “fail fast” to my attention. The article is sponsored by Martin Fowler (i.e. the King of Refactoring ™). The author is a consultant who “helps software teams work more efficiently”. (Did you ever notice that consultants always seem to have this kind of standard tag line?)
In any case, the article introduces the concept of “failing fast”. The idea is that a developer should get alerted to error conditions as soon as possible.