*There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
C. A. R. Hoare* From Joel’s discussion board…
I’ve just wasted 20 minutes or so on a nasty bug. I’d added a bit of test code and suddenly some other tests were failing but the reason for the failure seemed to be that a class’s vtable was getting screwed up and a virtual function was jumping off into hyperspace…
After some time stepping through the code for a while I could see that a function that should have been incrementing a data member was in fact stomping over part of the vtable.
In C++ every object has a “this” pointer. You could think of it as being passed as an implicit argument to every non static member function that the object has. It can never be null so why isn’t it a reference?
The reason I started wondering about this is that when using wiring objects together, such as when using parameterise from above, I often find myself wanting to pass a reference to the current class to some related object.
I needed to implement the same interface twice in one object today. It took me a while to remember how I do this kind of thing so I thought it was worth a blog posting so that a) I can find it at a later date, b) other people can tell me of better ways to do this, and, c) other people can use the technique if they want to…
There seems to be a wierd bug with .Net 1.1 and sockets…
In essence, this code:
using System; using System.Net.Sockets; namespace ConsoleClient; { class Class1 { [STAThread] static void Main(string[] args) { TcpClient _socket = new TcpClient(); } } } works with .Net 1.0 and fails with .Net 1.1. The error message on 1.1 is this; “Additional information: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full”, which is the long version of WSAENOBUFS.
I like nested classes in C++. They allow a nicely fine grained approach to naming. Where a class may need to be called CRegistryKeyIterator if declared at namespace level it can be called Iterator if nested inside the CRegistryKey class. The problem is I think I tend to overuse the feature…
I’m restructuring some code at present. This involves decoupling the IO Completion Port code for async IO from the socket server code in The Server Framework so that it can be used for file IO as well as network IO.
Looking back on my blog entries for 2003 it’s reasonably obvious that the big thing for me in 2003 was testing. TDD seems to work well for me and my clients. It’s not a silver bullet but it is a useful tool and I find that when you’re operating in TDD mode that nice code just unrolls in a nice, stress-free manner. What’s more, the code usually seems to turn out better than that produced without using TDD.
A combination of events in the run up to my Christmas break meant that I have ended up spending almost 2 weeks without feeling the urge to write any code. I’ve just chilled out and relaxed, watched some DVDs, saw LOTR ROTK, played some SSX3 and ate and drank too much.
At the weekend I started to get my head back into coding thoughts by restructuring a couple of libraries that make up The Server Framework.
Wayne Allen asks why so much code is so bad? Why the majority of code, even new code, that he sees as a consultant is terrible.
Meanwhile, Rory Blyth is complaining about “Paper bag” code.
I think Wayne hits the nail on the head with his comment about much of the problem being down to the individuals involved willingness to learn and change. But there’s more. Doing a good job requires lots of thinking, lots of self-discipline and lots of courage.
Ok, I usually hate those ‘me too’ blog postings but…
Here’s a “fix” for the fact that on Microsoft keyboards that have an “F Lock” key to change how the function keys work the default power up state is “wrong”….
From “The furrygoat experience”, via “ISerializable”. Thanks guys…
