Dennis Forbes talks about “Edit and Continue” in VS 2005 and asks “Is it, coupled with similar tool advances, making programmers sloppier, though?”
I think so…
In the Visual C++ debugger we’ve had “Edit and Continue” for years but I turned it off a long time ago as I didn’t find it that helpful. It enables and encourages quick hacky experimental fixes to running code. I never really liked that idea, I usually prefer to think about the problem rather than just hacking in a fix, and back in the early days of VC6 the whole incremental link/edit and continue thing sometimes introduced interesting bugs that seemed to go away if you did a full clean build.
Ben takes the “throw as an exception dispatcher” idiom to its logical conclusion by presenting a pluggable exception handler.
As Ben says “I’m not sure how many situations something like this would be useful in, but it fit the testing problem well and was fun to write anyway”. It’s not the kind of code you need every day, but it’s useful stuff if you’re working on a test framework, or if you’re interested in how you can use the “throw as an exception dispatcher” idiom.
I’m in the process of testing some of my code with Visual Stuio 2005 and the first thing I found that I needed to do was to upgrade my STLPort installation from 4.6.2 to 5.0.0 to get a version that built with VC8. Given that I like to test one change at a time I first upgraded my VC6 build to use STLPort 5; STLPort built fine with VC6 and all my tests passed.
I’ve been using the SetThreadName() function from the MSDN docs for ages to provide a way of distinguishing between threads in the VC debugger. I always thought it was a bit of a weird ‘API’ but had never really thought to wonder why. Steve over at “Bug Babble” explains how the ‘API’ works from the debugger’s point of view and, well, then it all becomes obvious. For some reason I’d always thought that the ‘API’ was communicating with the OS in some weird and wacky manner; I hadn’t twigged that in fact it was just communicating with the debugger using the only method it could, via raising an exception which gets routed through the Win32 debug API.
Ned Batchelder reminds us of the value of the C++ FAQ (Lite). It’s been a long while since I’ve looked at it yet Ned’s example shows that I’ve still a lot to learn about the subtleties of C++. I can think of a few places where I could use that throw; as an exception dispatcher example to replace some rather ugly macros.
I started back with an investment banking client this week. I’m working with the team that brought us “the refactoring project” and another small team, and integrating the trade entry system with some “xll” excel addins and some back end server software. Pretty standard fare for investment banking work…
I’ve worked with this client quite a few times over the years and it’s interesting to go back and find that they’re still using the systems that I helped them to put in place back in 2001.
Udi Dahan writes about managing dependencies in code at the ‘package’ level in “So many Dlls, so little time”.
“Sloppiness with dependencies. If two classes are independent of each other, and do not provide different implementations of the same interface, think twice about putting them in the same project/dll. Minimizing dependencies is the bread and butter of loose coupling. Break dependence on implementations by introducing interfaces in a separate project/dll.”
It looks like all of the hosting problems are now resolved. There was a brief period when the database and CGI were fixed and an MT configuration path hadn’t been updated so pages were not being rebuilt after comments were added but that’s now been fixed and the pages have been rebuilt to include the missing comments.
If anyone notices anything strange please leave a comment on this posting.
Robert Scoble, the “Microsoft Geek blogger”, has recently had a complaint that he only writes about Microsoft and he figured that he was in a rut and decided to get out of his rut by deliberately not writing about his usual topics of Microsoft, Google and Yahoo (GYM) for 100 posts… So, for the last 3 days he’s been writing about other stuff… There are problems with this idea though…
Whilst I’m ranting about the little things…
You still can’t create named versions of the .Net ManualResetEvent and AutoResetEvent, even in .Net 2.0. Wasn’t everything going to be fixed in Whidbey?
Of course, I realise that you can “simply” access the underlying Win32 API to do it, but a) why should we have to? and b) it’s not recommended that you do…
I guess the fact that the P/Invoke route isn’t recommended is the reason for the dearth of nicely packaged up solutions to this problem; surely anyone who needs this functionality would write an object that wraps it up nicely rather than doing it “long hand” like this?
