Friday, August 12, 2011

C++

It looks like I will have to add STL/C++ to my repertoire to deal with the Data Structures class I start in a little over a week. I picked up the second edition of Stroustrap's book (dated but beautiful) for $2.5 from a local used book store and will chew through it. Sometimes it's funny how much I enjoy dead tree editions of computer books, even with the lack of copy paste. I have an electronic 3rd edition, but I think I'll get through this in the meantime.

So, when playing around with Java over the years, I've actually found BlueJ to be one of the best working environments, largely due to the support for runtime creation of objects, and allowing exploratory programming. I think I'll use a mix of Code::Blocks and good old Emacs for the time being, but does a better solution exist? One in which files are presented as the parts of a class hierarchy and methods can be invoked in an interpreter. Code::Blocks seems straightforward enough for creation of boilerplate constructors, destructors, assignment operator, and copy constructors, automatically making headers and implementation files and including header guards.

As an aside, is there an IDE with built in support for TDD in C++? It seems like TDD might be my next side adventure in self-growth. I recently saw a few people from 8th Light give a live demo in python and ruby of a simple TDD walk-through for a trivial change counter. Having never taken principled software creation practices seriously (no more than sane names and proper decomposition of functionality, an 1970's level solution), this was intriguing. Not going to run out and buy Uncle Bob's books, but I'd like to see what proper unit test first program design feels like.

Constantly I need to suppress the 'knowledge' that C++ is a steaming pile of horse manure to dive forward and gain competency. Really, could you find a way to write const any more times in a declaration? Isn't there a better semantics for specifying this sort of compiler hint? One const to say that the arguments are unchanged, one const to say that the object is unchanged, one const to say that the return type is immutable. All using the same word, all dependent on context. I pity the programmers who are forced to think like the compiler to get work done. Although I was reading a talk by Kiczales Why are Black Boxes so Hard to Reuse where he points out numerous times the danger in an implementation deciding in advance what a typical use case will be.

No comments: