Miško Hevery over at the Google Testing Blog has a few things to say about Asserts and testing. He’s against asserts, specifically ones which perform null checks, as they get in the way of testing. Whilst I agree with his dislike of assertions (see here) I disagree with his dislike of null checks…
Miško complains that by having an object check passed in objects for null and assert if they are this causes him problems in testing where he knows that he doesn’t need the objects that are being passed in to test the functionality that he’s testing.
The latest release of The Server Framework is now available. This release includes the following changes.
The following changes were made to the libraries.
Admin Library - 5.2.5
No Change. C++ Tools Library - 5.2.5
No Change. Win32 Tools Library - 5.2.5
No Change. I/O Tools Library - 5.2.5
No Change. Socket Tools Library - 5.2.5
Fixed a bug in the dispatch of JetByteTools::Socket::IStreamSocketCallback::OnConnectionClosed() from within JetByteTools::Socket::CStreamSocket::OnFinalRelease(). We now ensure that the socket’s reference count is valid before calling the callback method.
A client has just reported a bug in version 5.2.4 of The Server Framework. The bug has, possibly, been present since 5.2.2 and relates to the dispatch of OnConnectionClosed() callbacks when a socket is released.
If a socket is still valid, i.e. it hasn’t been previously closed, when the socket is released for the last time then part of the clean up is to close the socket. Your code is informed of this by the OnConnectionClosed() callback being called.
Something that I find myself wanting in a debugger from time to time are breakpoints that only fire if the code has been entered via a specific route. You know the problem, you’ve tracked a particular issue down to one specific call sequence that occurs at a specific point in the code. The line you want to break on in this instance is also hit a lot via other routes that you don’t care about.
It’s now around a month since I started shifting the bulk of my source code from CVS to Subversion. In that time I’ve move most of my internal use code, and a couple of clients. I’ve done several client releases and developed several new features for The Server Framework on isolated development branches which have then been merged back in to the main trunk. I’ve also updated my continuous integration server to use the new source code repositories and, generally, just got on with it and lived with the new system.
I’m downloading the Windows 7 Beta from MSDN Subscriber downloads right now and the new Microsoft File Transfer Manager appears to be very very crap. The MSDN site insisted on updating the file transfer component before I could download and this version seems to stop every few minutes with errors about web server headers being missing. I have no proxies of my own that could be causing problems so I assume it’s a wider problem than just me… Anyway, it’s a pain that I have to keep hitting the Resume button ever few minutes…
In one of the original articles that introduced The Free Framework I mentioned that the original design was possibly lacking in that it required a critical section per connection and that this could be resource intensive. Shortly after I changed what was to become The Server Framework to use a lock factory which passed out instances of critical sections based on a hashing algorithm applied to a key that the caller supplied.
Converting a numeric type to a string format in C++ is one of those problems that was ‘solved’ a long time ago. The ‘standard’ method usually involves streaming the type to be converted into a std::stringstream and then extracting the resulting string representation. Something like this, perhaps:
#include<iostream> #include<string> #include<sstream> using namespace std; string itos(int i) // convert int to string { stringstream s; s << i; return s.str(); } int main() { int i = 127; string ss = itos(i); const char* p = ss.
The CVS to SVN code migration is going well. As recommended by a commenter I’ve switched from using a script to pull my tools libraries from their repository into The Server Framework examples build tree to using svn:externals. This works nicely and plays well with branches and tags (as long as you remember to update the svn:externals definition on your branch or in your tag so that it points to the correspondingly tagged version of your externals (but this would have been the same if I were using a script).
I’m in the process of moving my source code from a CVS repository to Subversion. The main reason for the move is so that I can move the repository onto one of my NAS devices so that it can be backed up automatically. I have a spare NAS due to the fact that I had a power supply fail and the fastest way to get up and running again was to buy a new one rather than waiting for the replacement PSU… Anyway, the development NAS has SVN running on it which means that I now have a RAIDed, UPS protected SVN server which gets backed up nightly to my ‘off site’ NAS via rsync…
