Joel Spolsky’s classic article, because I think we could all use the reminder sometimes.
Challenge: See how many architectures, products, services, and protocols from the (2001) article that you can swap out for their most recent (2009) replacements.
I’m going to start a semi-repeating series on “those things.” You know how at every job, there’s always “that guy?” Or if you’re a student and your schedule is different every day, there always seems to be “that day” of the week that sucks above all others? That’s the spirit of my “that thing” rants. Today’s flavor is about pointer syntax in C++.
If you use any language long enough, you’ll learn to love it. You’ll love this core language feature, and that standard library. You’ll become accustomed to it’s minor inconveniences, and if you do it long enough, you’ll find ways to circumvent them (or at least save yourself the typing). You’ll eventually get to the point where you feel more fluent in the language than with English… or is that just me?
I digress. Anyway, if you use that language even longer, you’ll learn to hate it as well. To dread “those” moments – few and far between as they may be – when you have to perform that one annoying task that your language specification, compiler, or platform makes a chore and a half.
With C++, “that thing” (or at least one of them) is undoubtedly, above all else, the pointer. And no, I’m not talking about an unsigned*, or a bool*, or even a char* (for those who know about character arrays; real men don’t use streams). I’m not talking about any complex nested data structures with addresses scattered willy nilly all about the place.
No… what I’m talking about are function pointers. Now don’t get me wrong – function pointers, in theory, are wonderful. They prove a tremendously powerful ally on the team of anyone brave enough to employ them. And many languages pull this off without a hitch. Python makes it a breeze. It’s none too difficult in PHP, either. However, sadly enough, C++ isn’t in the cool crowd. It’s a compiled language. It needs to know what you’re doing before you do it, and it needs to know it explicitly and unambiguously. So when it comes to function pointers – especially given that they’re a higher level concept – it’s no surprise that the syntax is a bit wonky. But honestly… what is this?
class A { private: std::string (B::*_name)( void ); public: std::string (B::*getName(void))(void) { return _name; } };
Okay, declaring A::_name is a bit annoying because the compiler needs to know beyond a shadow of a doubt what the precise signature of the phantom function is. This complexity is compounded by the fact that it’s not just some regular old function, but actually a nonstatic method of class B, which takes no arguments and returns a std::string. You know what, I can dig that. I see the elegance there.
But what in the name of all that’s good and holy is going on in line 5?!?! I’m declaring a member method in A called getName, which takes no parameters, and returns the function pointer _name. Not that big of a deal. But why the convoluted syntax here? You declare any normal member method with the pattern return_type name( parameter, list ). Oh, and on line 5 there at the end, with the (void))(void)? The first void is the parameter list for A::getName and the second is the parameter list for the pointed-to member. Yeah.
I understand that function pointers require a fair bit of complexity to pull off. I also understand that what I’m doing here (returning a pointer to a nonstatic method of class B inside from a nonstatic method in class A) is fairly esoteric, however I’m flabbergasted that the syntax is so inane that I had to corroborate several Google searches to piece together the correct syntax for this. Note, in this article, I don’t even begin to consider const-ness with these puppies – yeah; that gets ugly too.
Way to be that guy, Bjarne.
In a current project of mine, I kept seeing random unhandled exceptions float up to the top of my application. In cases where I suspect exceptions might be thrown, the code is smathered with some try/catch logic, per standard practice. I also have a healthy stack of catch blocks wrapping the contents of main(). Theoretically, that shouldn’t ever get executed.
Theoretically.
Which means, it was a good thing it was there.
Without waxing the specifics of the problem, I was generally unable to trace the source of a particularly difficult to reproduce std::exception that kept bringing the application down. Backed into a corner, I used the fail safe debugging method of the ages. I cast a very wide try/catch net, and then slowly tightened it down the call stack of my 70-some file large C++ project. Once I had pinned a sufficiently manageable block of code as the culprit, I had a brainwave.
I use GDB religiously (via Emacs) whenever I encounter any segmentation faults. What used to take 15 minutes or more to track, now takes a whopping 30 seconds a worst. One thing I’ve never done before, though, was to track exception logic with GDB. Finding the information was trying, but eventually, some Googling led me to an Apple mailing list entry with the name of a very low level exception mechanism, called __cxa_throw().
Using GDB to sleuth the origin of any exception is easy with that function name. Before you dive in, simply set a breakpoint for __cxa_throw. GDB will halt and take you right to the source of any exception as soon as one is thrown. Viola! Now, tracking the source of any mysterious exception is as easy as locating seg faults.