C++


Do two posts in a day  make up for missing Tuesday?

.NET

Brad Abrams points to a study about the savings achieved by ClickOnce deployment…$36,500. From the Microsoft Internal HR Application department.

Agile

An interesting article about Lockheed Martin using an Agile approach for the new F-35 jet.  Talk about a Scrum of Scrums…

A podcast with Jim Trott and Alan Shalloway about the value of Lean-Agile development.

Community

Larry O’Brien has prior art for a dubious patent: “Hyperlinking from a CD to the web”.  I suspect PubPat would welcome his help.

Scott Bellware has a plan for Microsoft…if he was king for a day.

Design

Uncle Bob ponders Coding Styles. They are a good thing, but it should just be about style, not content. Consistency should rule.  The problem I run into is that I use about 6 different IDEs (Visual Studio Classic, 2005, VB 6.0, 3 flavors of embedded IDE).  I would love having 1 editor, customize it, have the macros setup for comments & auto-styling. Ever tried to use slackEdit to do VB 6.0?

Tim Ottinger has an intro to auto_ptr and Single ownership in C++.  Good stuff…if only our C++ code was VC 8 vintage…

We got this one right under the wire, thanks to Harry Connick Jr.’s New Orleans Tour.

I would point you to Roy Osherove’s entry on Object Oriented design for Testing.  I like it!

Just finished listening to Scott Hanselman’s Hanselminute #49 with Bruce Payette – interesting stuff about PowerShell.  A new book I just have to have.  If you’re an system administrator on Windows, do yourself a favor and learn PowerShell.  Your life will never be the same.

We have an extensive C++ code base for our data acquisition back-end.  You could euphemistically call it “organic”. We’re trying to improve the code base by refactoring.  If you deal with legacy C++ code, you really need to get Michael Feather‘s book Working Effectively with Legacy code.  The man is a genius!

Since this code base had no unit tests, and we don’t like refactoring without some tests, we decided to investigate what was available in the windows C++ world.  We decided to use CppUnitLite simply because it was easy to integrate with our vintage tools.  We soon ran into a minor stumbling block…
Our back-end consists of multiple DLLs, mostly involved with acquiring data from various devices (e.g. a plug-in type of architecture). We wanted to run the Unit Tests on objects internal to the DLLs; those objects are not exposed to the DLL clients.  It is simply not practical (or advisable) to expose those objects.

The solution:  put the unit tests inside the dll, and expose a single function to perform the actual test execution.  You then have a simple external driver program load the dll and call that function.  No need to expose your guts.

Clearly, you want to be careful to not have the unit tests in the version of the DLL you ship out.  Simply have a #define controlling wether the tests are compiled in or not.

Just a neat little technique for those running into this problem.