Gareth Wilson from Fog Creek interviewed me the other day for their series on the lives of developers; we talked about playing Dam Buster on the Commodore PET and typing in programs in WATCOM VI and all kinds of stuff. Thanks Gareth, I enjoyed it very much. You can read the interview here.
Last time I explained why the designers of C# wanted to have both checked and unchecked arithmetic in C#: unchecked arithmetic is fast and dangerous, checked arithmetic is slightly slower but turns subtle, easy-to-miss mistakes into program-crashing exceptions. It seems clear why there is a “checked” keyword in C#, but since unchecked arithmetic is the default, why is there an “unchecked” keyword?
One of the primary design goals of C# in the early days was to be familiar to C and C++ programmers, while eliminating many of the “gotchas” of C and C++. It is interesting to see what different choices were possible when trying to reduce the dangers of certain idioms while still retaining both familiarity and performance. I thought I’d talk a bit about one of those today, namely, how integer arithmetic works in C#.
Hey all, apologies for the sudden and very long break there. A number of people asked me if I was OK, falling off the face of the earth like that — thanks for your concern, I am fine, just over-busy.
Ricky Jay has a line in The Spanish Prisoner where he says that when your hobbies interfere with your work, that’s fine, but when they interfere with each other, you have a big problem. I had that terrible problem back in November and something had to give, so I stopped blogging and woodworking for a while there. The combination of a tight deadline at work, helping Mark get the next edition of Essential C# ready for later this year, and working on a series of educational videos ended up consuming all my available bandwidth for technical stuff.
Let’s return now to our modified Zork graph fragment from a couple episodes back:
It is pretty obvious just from looking at this graph that if you start from the Troll Room and follow the arrows, there are four rooms that you must enter no matter what combination of edges you take: the East-West Passage, the Dam, the Dam Lobby and the Maintenance Room. And moreover, we’ll encounter them in that order. Let’s call these nodes “the inevitable nodes of the Troll Room”. Continue reading
Last time we made a little recursive algorithm to walk around a directed acyclic graph, or DAG. I made that algorithm a member of the graph class, but did you notice something about it? It did not access any private member of the class. Rather, it only used the public interface to do its work. What information do we need to find all the traversals of a DAG starting from a given node? Only the set of edges which come off that node, which we could determine from a delegate! We could in fact have written this algorithm as the following static method: Continue reading
Last time we built an immutable structure representing a labeled directed graph, and then built a directed acyclic graph stolen from Zork: (click for larger)
The question at hand is: given a node in a finite DAG, what are all the possible traversals of edges through the graph starting from that node? We know that any traversal of a finite DAG must eventually terminate in a node that has no outgoing edge, and that there are finitely many such traversals. Continue reading