STL containers are great. Rather than have to worry about writing doubly linked lists, efficient maps, and other such data structures you just grab one from the STL and you’re away.
Unfortunately the STL containers have quite a large ‘surface area’. Their interfaces are rich because they are generic containers. Often the container you actually need is much more limited in scope and in such situations I always find it’s worth wrapping the STL container and providing a more appropriate interface to the user.
If you don’t write the code are you doomed to forever be thinking that the abstraction is all in the wrong place?
Another day, another dollar. Starting with a new client, well starting back with an old client, and doing that ‘get your head around the source’ thing…
Way back in mid November, before we dumped our building’s managing agent for being worse than useless and possibly stealing from us, I was working on some POP3 code. I had some down time today so I decided to drop back into it and see if I could move things along a little.
In summary, having lots of tests helped…
I haven’t done any development on the POP3 code for 3 months.
Surprisingly enough the Bluetooth server “technology preview” has generated quite a bit of interest from potential clients, which is nice. In a similar spirit, I’m making the compiled version of our server that uses the OpenSSL Toolkit available for download. This code uses our freely available IOCP server framework and adds SSL support using OpenSSL. We have an SChannel version in the pipeline for those of you who don’t want to have anything to do with OpenAnything…
My birthday lasted all week, which was good. I celebrated on the day at Strada in upper street, on Friday at the Almeida and on Saturday at Curry Special.
Thanks for all the wonderful presents. Right now the most “interesting” is probably the Vew-Do balance board that Chris and Hilary bought me… I’d really noticed a big improvement in my skiing from the extra balance work that I’d done during the summer on roller blades.
Today turned into a day for pondering complexity, abstraction and memory management and watching Pirates of The Caribbean on DVD…
I experimented with a version of the buffer allocator that allowed a user defined memory allocation policy. It worked, but it was, I think, unnecessarily complex. If the buffer allocator itself lay behind an interface then that’s enough flexibility. Additional abstraction, with an abstract allocation policy in addition to an abstract allocator seemed a tad too abstract… At some point you have to actually make the decision and write the code that does the work.
As I mentioned earlier, I found a memory leak in a piece of code and was lamenting the difficulty in providing automatic tests for such a think when you use new and delete directly. I’ve thought about this some more and I’m now slightly less concerned…
The bug was in the one place that I wasn’t using some form of factory to manage dynamic allocation. I was allocating a ‘per socket’ data structure when a connection was established and supposed to be deleting it when the socket was released; I wasn’t.
So, what brought on those musings on complexity? There’s a bug in the recent public release of The Server Framework code. It’s in one of the example servers. Some code got snipped out and it shouldn’t have been and the result is a memory leak. The code in question doesn’t have tests, but that’s not the point, it would be hard to write automated tests that would have caught the problem due to the fact that I, as a designer, made an unchangeable decision for the user of the code.
I find that these days I prefer my complexity to be obvious. Things with hidden complexity aren’t any less complex, they’re just less obvious. If you make all of your complexity obvious then you know which pieces of code are complex and you can focus your attempts at simplification on the right places…
Some of this comes from the testing that I’ve been doing; liberal use of parameterize from above means that an object that uses several services is explicitly given those services when you create it.
Following my tooth brush revelation about AcceptEx earlier in the week I found some time today to test out my ideas.
The implementation went pretty smoothly. It was helped by the fact that I had a previous attempt at using AcceptEx floating around. It was helped more by the refactoring that I’d done recently and the fact that it was easy to take the tests I had for the listen/accept version of the socket server code and adjust them to work with the new AcceptEx version.
