Here’s a nice piece by Rico Mariani about why Visual Studio is unlikely to go 64 bit any time soon. In a nut shell, unless you have very large data sets that need to be kept in memory you might be worse off as a 64 bit process than you are as a 32 bit process on a 64 bit operating system. Food for thought.
Eric Lippert has an interesting blog posting (here) on how sometimes you can be so focused on fixing the bug you fail to step back and take a better look at the actual problem that you’re trying to solve.
I’m guilty of this and, with me at least, it doesn’t only apply to bug fixes. Sometimes I can become overcommitted to a design to the point where I don’t recognise that it’s just one design option I treat it as the only design option.
I’ve just spent a little too long trying to track down a bug in a mixed mode DLL that I’m building. The DLL exposes a set of entry point functions that are defined as taking a single pointer argument and lies to the application that hosts it so that the application can call it with various numbers of arguments. The arguments could change from call to call or from ‘session’ to ‘session’.
I’m currently wrapping a server’s client side API in an ATL COM object for a client. The COM object will be used to communicate with the server from managed code or VB or other COM compatible systems. It’s a fairly straight forward process as the original ‘C’ DLL interface client API was built with this kind of thing in mind and I’ve done enough C++ objects wrapping a ‘C’ API conversions in the past to make the whole process relatively painless and straight forward.
Well, I’ve finally done something that I’ve been meaning to do for a long time. I’ve written some non-trivial assembly language code. Up until recently I wasn’t expecting this to be embedded assembly, but it actually seems like a sensible way to get into this low level stuff. Programming an 8bit RISC microcontroller in assembly is considerably easier than trying to do something with a PC. The chips are cheap (as chips), the tools are free, there’s an active user community and the electronics required is relatively simple.
I’m in the process of upgrading another client to v6.0. These guys write multi-user game systems and have a fairly complex CLR hosting custom application server. Anyway, I was hoping that we’d have a few easy performance wins from the changes that have gone into v6.0 and these gaming guys are possibly even more hung up on performance than my banking and trading clients.
The good news is that the changes in how we convert numbers to strings has drastically improved performance in their debug builds where they have lots of logging going on.
Herb Sutter has just published an interesting article over at DDJ on correctly using thread pools: Use Thread Pools Correctly: Keep Tasks Short and Nonblocking.
It’s not rocket science and it doesn’t deal with platform issues but it’s a useful summary of why The Server Framework’s thread pools operate as they do. Note that on Windows you can use IO Completion Ports to manage the work queue into the thread pool and this can keep the number of threads that are scheduled to run at the optimum number so that the pool operates at the ‘correct load’ for most of the time even in the presence of blocking tasks.
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.
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.
