On reinventing the wheel

For as long as programmers have been writing code, there’s been this idea that we should avoid “reinventing the wheel” – that we shouldn’t waste time writing useful bits of code that have already been written by other people.  And – conversely – that we should make our code general enough so that it can be reused.  And pretty much everyone will nod their head in agreement and then go right ahead and reinvent the wheel anyways, ignoring libraries that others have written.  So either we need to find some way of actually making people practice what they preach – or perhaps we should just let go of this idea.

Wii don’t like exceptions

You may have heard me say that threads are the Devil himself.  Well, I stand by it – and present more evidence.

Yesterday I added the last missing feature to Wii Plasmacore: MIDI music playing.  Everything seemed to go smoothly – music was playing and everything – until the Wii randomly froze.

We looked at each other: “Shit!” we said at the same time (this whole phrase is rhetorical and meant to impart the mood and dramatic flair of a cop-buddy action-drama-mystery movie).

Data structure visualization

Noah found this really cool applet that visually and interactively demonstrates how the latest data structures work – including Red-Black Trees and Skiplists, among others:

http://people.ksp.sk/~kuko/bak/index.html

Inherited constructors

Recently my friend Paul remarked on Slag’s inherited initializer methods. Specifically, how they can cause bugs when you create an object and accidentally use an initializer that’s inherited from a base class instead of the one that you’re supposed to use.

Java and C++ don’t allow inherited constructors. Slag does. What’s up with that?

Determining Heap Allocation Overhead

Dynamic memory allocations generally have a small, fixed amount of associated overhead that the OS uses to keep track of each allocation – 8 to 32 bytes usually.  Notably this meta-info is only necessary when the memory is freed – not when it’s in use – to determine the size of the memory that’s being freed and possibly give links to adjacent allocation blocks to aid in coalescing (defragging) unused memory.

After an embarrassingly long period of time scouring the net for info on the byte overhead for Windows OS I stumbled upon the blindingly obvious do-it-yourself solution: you just allocate two small things in a row and subtract their locations, e.g.:

  int* ptr1 = new int();
  int* ptr2 = new int();
  cout << "diff: " << ((char*)ptr2 - (char*)ptr1) << endl;
  delete ptr1;
  delete ptr2;

There’s actually still a bit of uncertainty due to alignment and round-up, but you can investigate that by trying different-sized allocations.  Basically what I turned up was that in the Cygwin environment there’s an overhead of 4-8 bytes while in Windows Vista proper there’s 24-28 bytes of overhead.

Malloc Info

Here’s a page with some good info on how standard memory allocation (malloc) schemes work:

http://g.oswego.edu/dl/html/malloc.html

Low-level coding part 1.1: Using ‘&’

Re: Geof’s comment on Part 1 – here’s some more detail on the “&” operator.

Say there were 4 variables:

int a;
int b;
int* ptr;
int** ptrptr;

and say those 4 variables lived at these 4 memory locations starting at 0×400:

0x400 [ (empty) ] a
0x404 [ (empty) ] b
0x408 [ (empty) ] ptr
0x40c [ (empty) ] ptrptr

Now let’s set a value for each of those variables: