Calvin and Hobbes

Growing up as a kid I looked forward to reading the newspaper comics everyday. I ate breakfast and read the day’s comics in the same order always leaving the best for last. Calvin and Hobbes was always something I looked forward to and I was sad when Bill Watterson decided to move on from making it. I didn’t understand what it’s like to work on the same thing for 10 years so it didn’t make sense to me, but as an adult I get it.

Five years ago I read the entire Calvin and Hobbes collection and wrote down which comics were my favorite. The comics still held up and I found a bunch that I liked, but none quite as much as the very last one that was made. The comic has taken on different meaning for me as I’ve grown older – at first it made me sad because the comic was over, but now it makes me happy because Watterson was starting off on a new adventure. Ashley bought me a framed copy of it a couple of years ago for my birthday and we have it hanging at the bottom of our stairs.

I’m pretty deliberate about the tattoos I get, so even with all of this history and feelings about the series and the specific comic, it still took me a year or two to finally get a tattoo of it. I’m so very happy with how it came out and how Christopher Gay was able to take the comic and form it to my arm in a unique way.

What’s in a name?

When my girlfriend (now wife) and I were talking about getting married, the question of what we would do with our last names seemed to come up quite a bit. Mostly, the questions were related to whether or not she was going to take my last name of McGee. In our culture it’s the norm for a woman to take the man’s last name so much so that some people even expect it. Each culture has its own way of choosing a family name. My wife and I aren’t firm believers in tradition for tradition’s sake, so we talked a lot about what we would like to do with our last names.

The Choices

My original last name: McGee
Her original last name: Kolberg

  1. She takes my last name
  2. I take her last name
  3. Neither of us changes our name
  4. We hyphenate our last names (hers first, mine first, or original last name first for each of us)
  5. We take a last name and put the other last name as a second middle name for each of us (ie: Austin Daniel Kolberg McGee)
  6. We combine our two last names into a mashup of our two original names (ie: KolGee, McBerg, etc)
  7. We combine the letters of our last names in a scrabble type way to make up a new name
  8. We make up a completely new last name

The Reasoning

Right away, we knew that neither of us wanted to do option 1 or 2. The origin of a woman taking a man’s name is not a particularly happy one. As a tradition it’s moved away from the origin, but we still didn’t want to do it anyway. I didn’t want to take her name because I quite like McGee and the genesis of the name. Neither of us had a problem with option 3 except we both really wanted to have the same last name. It’s annoying to have people assume that you have the same last name when you don’t which was already happening to my wife before we were even married. We also had to deal with small things like not being able to have both of our names on the call box at our apartment. At our apartment complex, deliveries must be addressed to the person on the callbox, which meant that whenever I ordered something I had to address it to my wife. We decided that if we couldn’t come up with an agreement, not changing our last names would be the fallback that we’d both be ok with, but it wasn’t our preference.

Neither of us particularly liked the idea of hyphenating our names. We didn’t like how it’d look and it didn’t solve the problem of whose name would come first. Option 5 had the same problem (unless you come out with the awesome name of Troy Adam West Lawlor, of course), so we nixed that as well.

That left us with options 6, 7, and 8. I don’t think we ever seriously considered option 8 as we didn’t have any ideas that sounded like us. We define ourselves by our last names, so it was hard to think of giving them up entirely. We had kidded about doing option 6, but the names that we could come up with didn’t seem to fit either. They seemed lighthearted or frivolous instead of being awesome.

The Favorite

When we looked at option 7 (the scrambling of names together to create an entirely new name), it fit all of the criteria we wanted in a last name. We got to keep parts of both of our birth names, we would have the same last name, and we’d come up with something that both of us would like. We sat in a bar on the Isle of Skye in Scotland, Ashley drinking Baileys and me drinking Jura scotch, and wrote down all of the combinations of our names that we could come up with. We eliminated them one by one until we found the one we liked the most. Using Kolberg and McGee as the origin of the letters, we came up with Kelmore.

We didn’t immediately decide to change our names, even after we had the name picked out. I make big decisions at a glacial pace, so it was a month or more before I decided to go through with it. Filling out the paperwork (a LOT of paperwork) and going in front of a judge at the courthouse to get it legally approved finalized the whole process.

A Year Later

It’s been almost a year since we changed our last names. It took a while to get used to the change, but I definitely feel like a Kelmore now. I’ve come to really like our shared last name. We seem to be the only people in the world with it, and yet it sounds like an Irish last name (of which we’re both descendents from). When we’ve told people about our choice, we’ve gotten responses ranging from: “That’s awesome!” to a family member calling me their greatest disappointment. It’s a strange mix of reactions.

I’m writing this post mostly so that people know that there are other choices out there. When I told one of my coworkers, he didn’t realize what we did was even an option, and now he and his fiance are planning on making up an entirely new last name when they get married. Choosing the traditional method of taking the man’s last name is not a bad choice, but thinking about your options first is always a good idea. Choose what you think is best for you and your partner, you’re going to have that name for a while.

Smash Brothers Documentary

This documentary is surprisingly good to the point where I liked it better than most real documentaries I’ve seen. It’s quite long, but pretty damn good all the way through.

I can remember playing Smash Brothers Melee for hours on end during my Freshman year in college. I was never particularly good, but it was an enjoyable game (except when Ross would destroy us repeatedly). This documentary brought back all those awesome memories.

Beer and Programming: 2



Idjit! – Dugges Ale- & Porterbryggeri AB: I generally love stouts and especially imperial stouts, but Idjit just didn’t grab me. It was incredibly thick (at points almost feeling chunky) and just had too heavy of a taste. It felt like they tried to make the imperial stouts to end imperial stouts but just went too far. Not really worth picking up.
Punkin Ale – Dogfish Head Brewery: Dogfish Head always puts out one of my favorite pumpkin beers, and this year is no exception. As far as pumpkin beers go, it’s on the lighter end with the pumpkin flavor not overwhelming you, but instead being a nice accompaniment to the brown beer. I think I still like the Elysian’s: The Great Pumpkin better, but that’s just because it matches the styles I tend to like more. Good for a pumpkin style beer.
Flipside Red IPA – Sierra Nevada Brewing Co.: Reds are my favorite beer type, so seeing a Red IPA was intriguing to me as I’d never known that was a thing. At first taste, it definitely reminds you of a solid red, but then you notice a bitterness to it from the IPA part afterward. It’s definitely a decent beer, but I think in the end I’d rather have a red or an IPA, I don’t think they need to be combined. Good for a red IPA; something to try once, but not a regular beer.
Narwhal Imperial Stout – Sierra Nevada Brewing Co.: I can’t speak highly enough of Narwhal. It’s one of my favorite Imperial Stouts, if not my absolute favorite. It’s thick, but not especially so like the Idjit. It has hints of coffee, but isn’t overpowering. And lastly, it’s fucking delicious. I love it so much, I’ve picked up two four packs to put in my beer cabinet to save for later when I can’t get it anymore. Pick up this beer if you see it, you won’t regret it.


I haven’t done much, if any programming at home this week, so I thought I’d talk a bit about some stuff I’ve already worked on in my engine. One of the first things I worked on was a memory manager, since C++ is not terribly good at tracking memory and letting you know when you’ve leaked it. Memory management is one of the hardest things for people to learn when using C++ if they’ve come from a managed language before and for good reason; it’s not something you learn via learning the language, but instead you learn by messing it up so many damn times that you get into a rhythm when programming new things. On windows, there is a very easy way to see when you leak memory when exiting the program (and potentially during, if you want to do snapshots).

As a primer for how Windows handles memory leak detection, you can read MSDN’s page about it, which has fairly good samples. The short of it is, you can include this code, and it’ll automatically spit out stuff at the close of the program to tell you which bytes are leaking.

// top of file
#include <stdlib.h>
#include <crtdbg.h>
// entry point into the application
int WINAPI WinMain(__in HINSTANCE hInstance, __in_opt HINSTANCE hPrevInstance, __in LPSTR lpCmdLine, __in int nShowCmd)
#if defined(_DEBUG) && defined(WIN32)

If you were to do an: int* int_ptr = new int;
That will spit stuff out like:

Detected memory leaks!
Dumping objects ->
{570} normal block at 0x00E26948, 4 bytes long.
Data: < > CD CD CD CD
Object dump complete.

Unfortunately, this isn’t terribly helpful! It might be if the data were a string, but when the data is an object, the output is relatively worthless. If you get lucky, the leak will occur at the same time every time, and if that is the case, you can put breakpoints on the creation of the data (the 570 in this example means it was the 570’th memory allocation).

So where do we go from here? A memory manager is the next step. We want to be able to both track our allocations better, and optimize how memory is created at run-time so we don’t have lots of little allocations slowing us down. There are two real ways to go about doing this; you can either overload the new operator or create an insertion point into which all memory is allocated and track it that way. The former is easier, but a bit messier, and the latter is something you probably want to do in the long run. I’ve done both before and in this instance I decided to go the easier route by overloading new and delete.

You can track all uses of new by doing:

inline void* operator new(size_t size, const char* file, const int line)
	void* ptr = malloc(size);
	MemoryManager::GetMemoryManager()->AddAllocation(ptr, size, file, line);
	return ptr;
inline void operator delete(void* ptr, const char*, const int) throw()

	#define DBG_NEW new(__FILE__, __LINE__)
	#define DBG_NEW new

You have to not just overload those functions, but all of the different types of new/delete (including the ones you created by redefining new as DBG_NEW). You can see all of them here. I’ve had some odd problems with code that overloads new, but doesn’t include the throw() part in the functions (even when I have no exceptions turned on), so it may take some fanangling before they work, but they should be good.

For the internals of the AddAllocation and RemoveAllocation functions, they’re pretty simple. They’re just a map of the pointer to the data that was allocated (size, filename, and line number).

struct MemoryAllocation
	MemoryAllocation() : _size(0), _filename("default"), _line_number(0) { }
	MemoryAllocation(const unsigned int size, const char* filename, const int line_number)
		: _size(size), _filename(filename), _line_number(line_number)
		// do nothing
	unsigned int _size;
	const char* _filename;
	int _line_number;

void MemoryManager::AddAllocation(const void* ptr, const unsigned int size, const char* file, const int line)
	_allocations[ptr] = MemoryAllocation(size, file, line);

void MemoryManager::RemoveAllocation(const void* ptr)

Record all of that information and you’re good to go! The example we had above with the integer being allocated (but not deleted) now looks like this when we spit the information out on close of the application:

c:programmingsideprojectsourcemain.cpp(48): Memory Leak at 0x00E26948 size: 4 bytes

This is MUCH more useful. This still doesn’t get us all the way to complete usefulness, however. What if you have a function like:

int* CreateInt()
	return new int;

That line and file will always be the same and never return what is actually important, the original caller! So how do you find out the important information? You get the callstack and keep that around in addition to the other information. I haven’t done that yet, as it’s platform specific (and in some cases a pain in the ass), but Google is your friend. It’s next on my list if I need to make any additions to my memory manager. This will allow you to see where all allocations are created from.

So how does this break down and why did I say it was the lazy way to go? Good questions! First, it breaks down when you have things like different libraries or third party dlls that will allocate/deallocate memory. It depends on how they’re created, but generally speaking you shouldn’t expect third party code to ever allow you to track these kind of allocations. In addition to that, because you’re overriding new, that means that other people are able to override new as well (including your coworkers or friends)! This means that if you compile with code that’s not yours and it does bad things, it could completely negate what you’re trying to do. It’s the lazy way to go because it works if everything you work with uses new. As a counter example, the standard library, like std::vector, will not allocate via new, so you can never see memory stats via that method of memory allocation. C++ is really hard to track all memory allocated in a program. Be wary of static allocations as well.

In the end, this is a very easy way for C++ applications to track memory allocations, but not expend too much time to write a true memory allocator like the Bitsquid engine.

Please give me ideas and/or comments about this post as I’d like Beer and Programming to become a weekly post. It takes a lot of work for me to do, but I enjoy it so far, so I’m going to continue it until I either run out of ideas or people stop caring about my posts.

Beer and Programming: 1