So, if you’ve ever tried to drag a folder from the filesystem into VS Solution Explorerer, sure it’ll recursively add all the files, but it wont mirror the folders in the solution, so you end up with every file placed at the root level of whatever “filter-folder” you dragged it into. This is very annoying when you have a project with say ~1,500 files.

I thought about how I could get around this and have the Solution Explorer folders mirror the filesystem, first obvious option was write a shell script or macro to do it. So I fired up VS macro explorer and lo-and-behold theres a Sample macro which ships with VS called “AddDirAsSlnFolder”.

Looking very promising I checked out the source code, and sure enough it does exactly what I needed. The only thing I had to do to get it working exactly right was add “.svn” to the exclusions list (this is down the bottom of the source file and should be clearly visible next to all the other exclusions in the list)

Enjoy.

Just a quick note, I thought others might find this helpful as well. In our level compiler, a bug which somehow went un-noticed for a little while was causing bounding boxes to not be calculated properly. This turned out to be a simple initialization oversight.

Vec3 maxValue, minValue;

ofcourse the default constructor would initialize both vectors to [0,0,0]. This is useless when trying to determine a bounding box which lies entirely in the negative part of all axies (because no vertex in that area will ever excede maxValue, which has incorrectly been initalized to zero). The fix was simple, but it reminded me of another C/C++ quirk over numeric limits.

The fix, one would think, would be something like this:

const float FLOAT_HIGHEST = std::numeric_limits<float>::max();
const float FLOAT_LOWEST = std::numeric_limits<float>::min();
Vec3 maxValue(FLOAT_HIGHEST, FLOAT_HIGHEST, FLOAT_HIGHEST);
Vec3 maxValue(FLOAT_LOWEST, FLOAT_LOWEST, FLOAT_LOWEST);

But, you’de be wrong. If you were using numeric_limits<int> that would work fine, but numeric_limits<float>::min acutally returns the lowest representable positive float (this is to help calculate another issue with IEEE floats see: http://en.wikipedia.org/wiki/Denormal).

Boost provides a clean solution for this in their “bounds” package.

I’m tempted to just go “-numeric_limits<float>::max()” (that is pretty much what the boost code will compile down to) but I like consistency, and I don’t want to worry about any (if any exist?) unmatched upper and lower values like 32 bit signed ints have, I’m no float expert…

Just a short post. Today I took a quick tally of the technologies we’re using. 

• OpenGL 3.0
• OpenGL-ES CM 1.1
• MSVC++ 8
• GCC 4.0.1 (Apple) & GCC 4.4 (Linux)
• C# .NET 3.0 (or 2.0?)
• XNA 3.0
• XCode 3.1
• Eclipse CDT 5.1
• Visual Studio 2005
• SVN

I haven’t blogged in a while now, so I thought I’d write something about a new personal project I’ve started. I entitled the post “relearning C++” because though I know lots of the language quirks and the nitty-gritty of C++, I have considered the past year or so a total re-introduction in the way I apply C++ and in particular, go about developing software using C++. For 10 years now I have used C and C++ in my daily life, being self taught from an early age it has lead to lots of painful (to say the least) learning experiences and I would have to say that up until recently my C++ code has had that “self taught” feeling to it - Most of you know what I mean, mediocre variable names, slightly odd coding styles, choosing brevity over clarity and so forth.

The last few years working with Java in the industry has given me a little bit of insight on producing quality software over software that just does what it’s supposed to, this is the “relearning” I refer to.

The new project has been written in a unit-test centric manner, that’s not to say its TDD nor has it 99% code coverage, but unit-test are part of the center stage. Additionally, we are making good (not over-the-top) use of the collection of powerful Boost libraries, and using these meta-programming/template heavy libraries has definitely learned me a thing or two about C++ - I guess that’s the thing about C++, no matter how long you’ve been using it effectively, there’s just so much to know and there are always those “ahhh-haa [forgot about that!!!]” moments and I guess for me this makes things a bit more challenging, but a little bit more fun (but probably not as productive as it could be).

I wrote the unit testing framework for our project, quite a simple suite/runner system. The system has been valuable for us as a  2-man-decentralised-after-hours-team (2MDAHT) - basically self documentation for code and use-cases and full regression testability, which when communication is not as often as we’d like it, is a great way to make sure we’re always taking two steps forward and none back.

The system is also written thread-safe from the ground up, the unit tests and our design-test-implement-test  philosophy allow us to see deadlock situations during the design-test phase and then during implementation allow us to more easily replicate and fix deadlocks by drastically narrowing the window of code which could be causing the problem.

If you had asked me 2-3 years ago whether unit-testing C++ code was worth it, I would’ve almost certainly would have said “no” or at best “it depends”, today I would go so far as to say it would be a “must” (however I do appreciate the feeling of impending doom when faced with retro-fitting legacy C++ for unit testing).

Recently at work, I’ve been using XSLT transforms in our backend quite a bit. But the issues I’ve run into took stupid amounts of effort to resolve and it wasnt easy to find any kind of list of do’s and dont’s - so I’m gonna make one from the stuff I’ve just discovered!

• When dealing with DOMSource and DOMResult - always setNamespaceAwareness(true) on your DocumentBuilder/DocumentBuilderFactory !!! - otherwise you end up with empty Documents and no indicators as to why!
• Remember that an XSLT transformation is not guaranteed to return an XML document! Hence, Don’t automatically assume a DOMResult( docBuilder.newDocument() ) will return a valid object - if your XSLT doesn’t produce valid XML, you’ll get an empty DOMResult document node!
• Validation settings affect whitespace awareness - if you don’t have validation on, whitespace is NOT ignored, so make sure your XSLT is formatted correctly - the most common problem area is when you try to prettyfy your .xsl file using indentation etc. Remember that XSL is pretty much an in-place tempate file [Copy Contents -> Replace Stuff exactly where it's asked for -> Dump result!]

Lastly, and easy way to transform input XML and pretty print it.

TransformerFactory transfac = TransformerFactory.newInstance();
Transformer trans = transfac.newTransformer();
trans.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "no");
trans.setOutputProperty(OutputKeys.INDENT, "yes");

Document doc = buildXml(); /* get your XML document from somewhere.. */

StringWriter stringWriter = new StringWriter();
StreamResult result = new StreamResult(stringWriter);
DOMSource source = new DOMSource(doc);
trans.transform(source, result);
System.out.println(stringWriter.toString());