If you’re into writing C/C++ XLL addins for Excel and you’d like to help make sure that the new features in the new XLL interface provide all the functionality that you’d like, then it might be an idea for you to get in touch with David Gainer via the contact form on his Excel 12 blog.

I scored a 28, which is “above average”, so considerably nearer to Asperger’s than it is considered to be “normal”. Which, to be honest, seems about right to me. If nothing else, it might make you think… Via Steve Pavlina’s personal development blog.

Or, marvelling at my own, past, cleverness. I’ve been doing a lot of work on these Excel addins for my current client and, as I get back into the whole C++ XLL stuff, I start to realise just how cool my child of 2001 really is. The Excel addins run as a suite; the team I work with has different users within the bank and there’s some cross over but some distinct separation.

A while back Chris Baus wrote a little rant about prototypes. I started to write a piece that defended prototypes when correctly used and ran out of steam; or, more to the point, couldn’t really say very much except they’re OK except when they’re not, try not to get to the point where they’re not. Having just recently been bitten by a prototype that was trying to rise above its station, I now have more to say.

I’m currently working on some C++ Excel addins for an investment bank. I originally wrote the addins for them back in 2001 and they’ve evolved slowly ever since. Right now we’re adding some new functionality and, whilst testing some of the new functions in the test sheets, I noticed that the functions weren’t behaving themselves properly when the Excel Function Wizard was in use… The Function Wizard allows you to step through the creation of a call to an Excel worksheet function.

So here I am, writing a piece about how the C++/CLI destructor and finalizer stuff could have been a bit neater and I put together some sample code to demonstrate my point and it doesn’t do what the docs I mentioned yesterday suggest that it should do… Given this example class…. ref class Example { public : Example( bool throws) : m_count(s_count++), m_string(gcnew String("MyString")) { Console::WriteLine(m_count + " - Example(throws = " + throws + ")"); if (throws) { throw "Thrown"; } } Example() : m_count(s_count++), m_string(gcnew String("MyString")) { Console::WriteLine(m_count + " - Example"); } ~Example() { Console::WriteLine(m_count + " - ~Example"); delete m_string; this->!

Beware! The rules for when a destructor is called for a managed C++ class in Visual C++ are different than for “normal” C++ class. Jochen Kalmbach recently posed a simple question about a managed C++ class; “Will the destructor be called in a managed class if the constructor has thrown an exception?”. The answer and the comments are illuminating and, to be honest, somewhat annoying. In summary, yes, the destructor is called even if the constructor doesn’t complete, see here for more details.

ImplicitInterfaceImplementation - from Martin Fowler is an interesting piece where Martin suggests that it would be useful to be able to provide alternative implementations of a class’s implicit interface. That is, given a class that does not inherit from an interface, it’s sometimes useful to be able to split the class into an implicit interface, the public operations that it provides, and treat that as if it were explicitly declared as an interface from which the class derives.

Am I a curmudgeon of technology? You betcha - Ted Neward over at “The Blog Ride” explains why he’s cynical about new technology and suggests that we’d do well to have a little more cynicism. I agree with him, I tend to take a similar position having been let down by various “silver bullets” in the past. I think I decided that it was my time spent working with OLE DB providers that caused me to be more cynical towards the Microsoft technology hype machine; When someone brings me a “cool” new technology and claims that because simple things are so easy to do in a sample my complex problem will also be easy to solve using the technology I ask to see the code that solves my problem…

In the fight to make C++ code easier to reason about and understand, never underestimate the value of a name. Giving something a decent name is the first step in thinking about the concept at a slightly more abstract level. Abstraction is all about selective forgetfulness, by grouping together several related program elements, defining a concept and giving that concept a name you can, from then on, choose to work at the level of the name rather than the detail.