Welcome back, and thanks for picking up this April Fools’ issue of “@#$%ing Strange C++: I hate this language sooo much.” Today, let’s take our example code from last time and apply some textbook techniques to screw it u—improve its readability and reusability.

Why would anyone do this with example code written to show an entirely awful concept with an entirely contrived example? I don’t know.

Let’s backpedal to the important part: Vector3D. Hey, we named it Vector3D, so why does it only allow floats? Why doesn’t it do any vector-y stuff? LET US ADD SOME FUNCTIONALITY WHICH WE WILL NOT USE.

// HELL YEAH, LET'S TEMPLATE IT
template<typename Component_T = double> // STICK IN A DEFAULT, EVEN IF IT DOESN'T MAKE SENSE
class Vector3D {
public:
	typedef Component_T ComponentType; // YOU'LL SEE WHY WE NEED THIS

	Component_T x;
	Component_T y;
	Component_T z;

	// Component_T MIGHT BE A BIGNUM CLASS OR SOMETHING, SO WE PASS CONST REFERENCES
	Vector3D(const Component_T &x, const Component_T &y, const Component_T &z) :
		x(x), y(y), z(z) {
	}

Mmm-hmm, templates are a sure part of any messy C++ recipe. Once you learn them, you’ll never remember how to program well again. Let’s continue on to the operator overloads. We completely ignore the fact that infix notation makes no sense in a language that features prefix for everything else, or that these are all really constructors, so they’re better off as constructors in the “named constructors” idiom, or that nobody ever follows the same conventions for these “arithmetic” operators; we’re using them because they’re snazzy little bits of sugar coating.

	// OPERATOR OVERLOADS ALL OVER THE PLACE
	friend Vector3D operator-(const Vector3D &a) {
		return Vector3D(-a.x, -a.y, -a.z);
	}

	friend Vector3D operator+(const Vector3D &a, const Vector3D &b) {
		return Vector3D(a.x + b.x, a.y + b.y, a.z + b.z);
	}

	friend Vector3D operator-(const Vector3D &a, const Vector3D &b) {
		return Vector3D(a.x - b.x, a.y - b.y, a.z - b.z);
	}

	// WE DON'T CARE THAT SOMETIMES PEOPLE WANT THE INNER (DOT) PRODUCT
	friend Vector3D operator*(const Vector3D &a, const Vector3D &b) {
		return Vector3D(a.y * b.z - a.z * b.y, a.z * b.x - a.x * b.z, a.x * b.y - a.y * b.x);
	}

	friend Vector3D operator*(const Vector3D &a, const Component_T &s) {
		return Vector3D(a.x * s, a.y * s, a.z * s);
	}

	// LOLOL REDUNDANT
	friend Vector3D operator*(const Component_T &s, const Vector3D &a) {
		return Vector3D(a.x * s, a.y * s, a.z * s);
	}

	friend Vector3D operator/(const Vector3D &a, const Component_T &s) {
		return Vector3D(a.x / s, a.y / s, a.z / s);
	}

	// BECAUSE a.dot(b) IS LIKE THE OTHER OPERATORS, NOT BECAUSE INFIX IS GOOD
	Vector3D dot(const Vector3D &a) {
		return Vector3D(x * a.x, y * a.y, z * a.z);
	}

	friend std::ostream &operator<<(std::ostream &os, const Vector3D &v) {
		return os << '<' << v.x << ", " << v.y << ", " << v.z << '>';
	}
};

Alright, now that we have blinged out Vector3D for no apparent reason, let’s extend our Operation cla—oh crud, there’s unqualified types needing the typename keyword, template parameters, and angled brackets all over the place. What to do? We’ll typedef everything away, of course.

template<typename Vector3D_T> // DAMN, NOW WE HAVE TO TEMPLATE THIS
class Operation: public std::binary_function<Vector3D_T, typename Vector3D_T::ComponentType, void> {
protected:
	// WE NEED typename TO FULLY QUALIFY; DON'T ASK WHY
	typedef typename Vector3D_T::ComponentType ComponentType;
	// (ROYAL) WE DON'T FEEL LIKE TYPING THESE ANY MORE
	typedef void (Operation::*OperationPointerType)(Vector3D_T &, const ComponentType &) const;
	typedef ComponentType Vector3D_T::*ComponentPointerType;

	// a pointer to a const member function with params (Vector3D &, float) returning void
	OperationPointerType operationPtr;
	// store the component selection using a member pointer
	ComponentPointerType componentPtr;

Just for the hell of it, let’s derive from std::binary_function to pollute our class namespace and let us do weird, fancy things with argument binding in <functional> and algorithms from <algorithm>, <numeric>, etc.

public:
	Operation(OperationPointerType const operationPtr, ComponentPointerType const componentPtr) :
		operationPtr(operationPtr), componentPtr(componentPtr) {
	}

	void setComponent(ComponentPointerType const componentPtr) {
		this->componentPtr = componentPtr;
	}

	void setOperation(OperationPointerType const operation) {
		this->operationPtr = operation;
	}

I guess it’s a little better with the typedefs. But here we go with the operator() overload that makes this a proper std::binary_function:

	// HELL YEAH, LET'S MAKE THIS A FUNCTOR
	void operator()(Vector3D_T &vector3D, const ComponentType &x) const {
		(this->*operationPtr)(vector3D, x);
	}

	void add(Vector3D_T &vector3D, const ComponentType &x) const {
		vector3D.*componentPtr += x;
	}

	void sub(Vector3D_T &vector3D, const ComponentType &x) const {
		vector3D.*componentPtr -= x;
	}
};

Wait a minute. This almost the same thing as from the article, just all weird looking. Feeling duped? You should be. Templating will make you feel all empty inside like that. But let’s see what we can do with this now:

int main() {
	std::vector<Vector3D<float> > vs(5, Vector3D<float> (0, 2, 3)); // create five <0, 2, 3>s
	std::copy(vs.begin(), vs.end(), std::ostream_iterator<Vector3D<float> >(std::cout, " "));
	std::cout << std::endl; // print out the list

In case you haven’t noticed yet, that’s working code for writing stuff to a stream; you can actually get an output iterator from a std::ostream and copy into it as with any other iterator.

std::cout << "Negating vectors..." << std::endl;
	std::transform(vs.begin(), vs.end(), vs.begin(), std::negate<Vector3D<float> >());
	std::copy(vs.begin(), vs.end(), std::ostream_iterator<Vector3D<float> >(std::cout, " "));
	std::cout << std::endl; // print out the list

WHOA MAN, THAT’S A FANCY NEGATE. std::negate creates a class fitting the unary_operator concept, which is a functor of arity one. Specifically, it uses the templated class’s operator- in the functor to return the negative of whatever is passed to the functor.

More fanciness:

	Operation<Vector3D<float> > vectorOp(&Operation<Vector3D<float> >::add, &Vector3D<float>::z);
	std::cout << "Adding to component z..." << std::endl;
	std::for_each(vs.begin(), vs.end(), std::bind2nd(vectorOp, 1.f));
	std::copy(vs.begin(), vs.end(), std::ostream_iterator<Vector3D<float> >(std::cout, " "));
	std::cout << std::endl; // print out the list again

	vectorOp.setOperation(&Operation<Vector3D<float> >::sub); // note the use of & operator
	vectorOp.setComponent(&Vector3D<float>::y);
	std::cout << "Subtracting from component y..." << std::endl;
	std::for_each(vs.begin(), vs.end(), std::bind2nd(vectorOp, 3.f));
	std::copy(vs.begin(), vs.end(), std::ostream_iterator<Vector3D<float> >(std::cout, " "));
	std::cout << std::endl; // print out the list again

	return EXIT_SUCCESS;
}

Yes, there I am actually “binding” a fixed value to the second parameter of my functor, something which required the use of std::binary_function to work. There is a better alternative that doesn’t require this, nor restrict us to binary (arity-two) functors, nor require us to specify the parameter to bind in such a cumbersome way. It’s called boost::bind, and you’re not going to use it because you’ll discover that boost::lambda is better in every regard, and that you’ll be turned off by having to stick Boost’s bulk into code you found on a blog.

Next steps? Well, we should document the hell out of this. Mmm, yeah, let’s bring in some Doxygen, or even better, some lightweight boutique documentation generator! Let’s write some embedded documenta… eh, we’re too lazy.

Last time in Part 1 we looked at how member pointers helped us to “cache” the choice of a float member in a hypothetical 3D vector class, Vector3D. Then we used this member pointer storing the choice of component to add a float to an arbitrary component of a std::vector of Vector3Ds.

Now our goal for this article is to extend our code acting on vectors: instead of just adding to an arbitrary component of Vector3D, we’d like to perform an arbitrary operation instead. This means that along with the selection of component, we’d like to also store a selection of operation to perform on that component. Then we’d like to apply that operation to a Vector3D without needing expensive¹ conditionals or switch statements.

So let’s sketch up some code. Here’s a quick class that represents an arbitrary operation on a Vector3D, which stores which component to operate on:

// Represents an operation done against one component of a Vector3D
class Operation {
protected:
	float Vector3D::*componentPtr; // store the component selection using a member pointer

public:
	Operation(float Vector3D::* const componentPtr) :
		componentPtr(componentPtr) {
	}

	void setComponent(float Vector3D::* const componentPtr) {
		this->componentPtr = componentPtr;
	}

	virtual void op(Vector3D &vector3D, float f) const = 0; // interface to use the operation
};

Given the requirements and what we know about member pointers from the last article, this seems like a reasonable way to store the “arbitrary component” selection in a class. To realize the “arbitrary operations” part of the deal, you’d have to derive from this class into the actual operations, in a textbook example of polymorphism:

class OperationAdd : public Operation {
public:
	OperationAdd(float Vector3D::* const componentPtr) :
		Operation(componentPtr) {
	}

	void op(Vector3D &vector3D, float f) const {
		vector3D.*componentPtr += f; // specialize the operation as addition
	}
};

class OperationSub : public Operation {
public:
	OperationSub(float Vector3D::* const componentPtr) :
		Operation(componentPtr) {
	}

	void op(Vector3D &vector3D, float f) const {
		vector3D.*componentPtr -= f; // specialize the operation as subtraction
	}
};

Now, using polymorphism is a perfectly natural way to solve the problem for a C++ programmer. Just implement the interface by overriding op() and passing the component member pointer to the parent constructor: easy. Note the use of Operation::componentPtr to access the “cached” component selection. This might be how you’d want to use these classes:

void applyOperation(std::vector<Vector3D> &vs, const Operation &operation, float amount) {
	for(std::vector<Vector3D>::iterator v_i = vs.begin() ; v_i != vs.end() ; v_i++) {
		operation.op(*v_i, amount); // apply the operation to every Vector3D
	}
}

int main() {
	std::vector<Vector3D> vs(5, Vector3D(0, 2, 3)); // create five <0, 2, 3>s
	std::copy(vs.begin(), vs.end(), std::ostream_iterator<Vector3D>(std::cout, " "));
	std::cout << std::endl; // print out the list

	OperationAdd vectorAdd(&Vector3D::z); // create an "addition to .z" operation
	std::cout << "Adding to component z..." << std::endl;
	applyOperation(vs, vectorAdd, 1.f); // apply "addition of 1 to .z" to all vectors
	std::copy(vs.begin(), vs.end(), std::ostream_iterator<Vector3D>(std::cout, " "));
	std::cout << std::endl; // print out the list again

	OperationSub vectorSub(&Vector3D::y); // create an "subtraction from .y" operation
	std::cout << "Subtracting from component y..." << std::endl;
	applyOperation(vs, vectorSub, 3.f); // apply "subtraction of 3 from .y" to all vectors
	std::copy(vs.begin(), vs.end(), std::ostream_iterator<Vector3D>(std::cout, " "));
	std::cout << std::endl; // print out the list again

	return EXIT_SUCCESS;
}

Example output:

<0, 2, 3> <0, 2, 3> <0, 2, 3> <0, 2, 3> <0, 2, 3>
Adding to component z...
<0, 2, 4> <0, 2, 4> <0, 2, 4> <0, 2, 4> <0, 2, 4>
Subtracting from component y...
<0, -1, 4> <0, -1, 4> <0, -1, 4> <0, -1, 4> <0, -1, 4>

But there’s a lot of code duplication for the OperationAdd and OperationSub classes, isn’t there? You have to write a heck of a lot of code to account for what is essentially one character of difference between each operation.

In addition, as a design decision, shouldn’t selecting “which component” be similar to selecting “which operation?” Why does the latter require instantiating a new object of another subclass of Operation, yet the former requires only a call to Operation::setComponent?

To amend this, I’d like to introduce the member function pointer. It is exactly what it sounds like: a pointer to a member function, also known as “method.” A member function pointer can point to any method that has the same parameter list, return type, and const-ness as specified in the pointer’s type. Let’s see an example:

class Example {
public:
	void printA() {
		std::cout << 'A' << std::endl;
	}

	void printB() {
		std::cout << 'B' << std::endl;
	}

	static void printC();
};

void Example::printC() {
	std::cout << 'C' << std::endl;
}

void printD() {
	std::cout << 'D' << std::endl;
}

int main() {
	// member function pointers:
	Example example;
	void (Example::*printMethod)() = &Example::printA; // declare a pointer to printA
	(example.*printMethod)(); // prints 'A'
	printMethod = &Example::printB; // reassign pointer to printB
	(example.*printMethod)(); // prints 'B'

	// regular function pointers:
	// even though printC is part of Example, a regular function will do
	void (*printFunc)() = Example::printC; // see how the "&" isn't needed
	printFunc(); // prints C
	printFunc = printD; // here too, "&" is omitted
	printFunc(); // prints D
}

I think it’s pretty self-explanatory, but let’s go through it anyways. void (Example::*printMethod)() is the declaration of the “printMethod” pointer variable. This syntax should be ringing bells in your head if you know member pointer syntax and function pointer syntax. Note, however, that we can’t use just “Example::printA” to initialize the pointer; we need to use the address-of operator (&) as well. I’m not entirely sure why there is such a discrepancy between the syntaxes used for normal function and member functions. The fact that the parameter list has greater precedence than the .* and ->* operators leads to another unfortunate syntax: parentheses around the class instance, .* or ->*, and the member function pointer.

Now let’s try putting member function pointers to use in our Vector3D example. It’s really as simple as changing Operation to explicitly store the selected operation member function, rather than implicitly in the case of polymorphism (more on this later):

class Operation {
protected:
	// a pointer to a const member function with params (Vector3D &, float) returning void
	void (Operation::*operationPtr)(Vector3D &, float) const;
	// store the component selection using a member pointer
	float Vector3D::*componentPtr;

public:
	Operation(void(Operation::*operationPtr)(Vector3D &, float) const, float Vector3D::* const componentPtr) :
		operationPtr(operationPtr), componentPtr(componentPtr) {
	}

	void setComponent(float Vector3D::* const componentPtr) {
		this->componentPtr = componentPtr;
	}

	void setOperation(void(Operation::* const operation)(Vector3D &, float) const) {
		this->operationPtr = operation;
	}

	void op(Vector3D &vector3D, float f) const {
		(this->*operationPtr)(vector3D, f); // call the member (add or sub)
	}

	void add(Vector3D &vector3D, float f) const {
		vector3D.*componentPtr += f;
	}

	void sub(Vector3D &vector3D, float f) const {
		vector3D.*componentPtr -= f;
	}
};

All we’ve done here is add the two example operations (addition and subtraction) as methods of Operation, as well as a new member, operationPtr, which points to either add or sub². We’ve kept the op() interface the same, so the other difference is how we construct the Operation instance and how to change the operation selection:

Operation vectorOp(&Operation::add, &Vector3D::z); // create an "addition to .z" operation
applyOperation(vs, vectorOp, 1.f); // apply "addition of 1 to .z" to all vectors

vectorOp.setOperation(&Operation::sub); // note the use of & operator
vectorOp.setComponent(&Vector3D::y);
applyOperation(vs, vectorOp, 3.f); // apply "subtraction of 3 from .y" to all vectors

Note how the lines of vectorOp.setOperation(&Operation::sub) and vectorOp.setComponent(&Vector3D::y) look so… symmetrical. We can now move independently in the space of operations from the space of Vector3D components. This is known as orthogonality, which is just a fancy way of saying that this code feels nice to use.

Now about the technicals: if you understand the mechanism behind polymorphism, you’ll recognize that this solution is very similar to said mechanism. In fact, it’s likely more efficient. A virtual function call requires dereferencing the VPTR, looking up the appropriate member function from VTABLE (which you’ll now recognize is simply an array of member function pointers), and calling the pointer retrieved. This solution skips straight to calling the member function pointer—an elegant way to strip away unnecessary functionality and code duplication.

So there you have it, folks. I started writing these two articles when I looked online at the explanations for how to use member pointers and noticed that every single one of them showed completely pointless examples. They all seemed to describe pointers to members and member functions as an oddity, a silly way to rename a class’s contents.

Hopefully I’ve proven them otherwise and you now have an idea of how to utilize these little guys to construct cleaner, faster code.

Stay tuned for more “Strange C++.” Maybe. Actually, don’t count on it.

You should read “C++’s .* and ->* operators: Part 1” if you haven’t already.

1. “Expensive” meaning conditionals can cause additional per-element overhead when batch processing due to branch misprediction and the subsequent pipeline eviction, in superscalar pipelined architectures.
2. Actually, it can point to op as well, which would cause an infinite recursive loop. Oops.

If you’re like me, then you probably spend all of your free time reading C++ FAQ Lite for some reason. Of course I don’t do that, because that’d be kind of weird and antisocial, but I figure people like me are probably weird and antisocial. It’s a self-deprecatory safeguard for the sake of modesty.

At any rate, you’d have come across the rules for which C++ operators can and can’t be overloaded. Those in the “can’t” camp are the ternary operator ?:, the scope spec operator ::, the member-of operator ., and finally the .* operator¹. What the Bjarne Stroustrup is that?

In few words, the .* operator accesses an object’s member pointed to by a member pointer. The ->* pointer does the same thing, only it accesses the member of a pointer to an object, not an object or its reference. Unfortunately, this does nothing to clarify the operator’s use and introduces the additional question: what is a member pointer? This is the heart of the article, and I will explain through examples.

Let’s say we had the following class, representing a vector in R³:

class Vector3D {
public:
	float x;
	float y;
	float z;

	Vector3D(float x, float y, float z) :
		x(x), y(y), z(z) {
	}

	friend std::ostream &operator<<(std::ostream &os, const Vector3D &v) {
		return os << '<' << v.x << ", " << v.y << ", " << v.z << '>';
	}
};

This is how you could use member pointers, taking note of the use of the .* operator:

int main() {
	Vector3D v(0, 2, 3);
	std::cout << v << std::endl; // output: <0, 2, 3>

	float Vector3D::*componentPtr = &Vector3D::x; // member pointer to the x member
	v.*componentPtr += 1.f; // "dereference" it against instance v and add 1.f to it
	std::cout << v << std::endl; // output: <1, 2, 3>

	componentPtr = &Vector3D::y; // now point it to the y member
	v.*componentPtr *= 2.f; // "dereference" it against instance v and mul it by 2.f
	std::cout << v << std::endl; // output: <1, 4, 3>

	return EXIT_SUCCESS;
}

Now you might say: “Well, that looks like a whole lot of gibberish symbols to me. What does it mean and what does it do?”

Well, first we’re declaring and initializing a variable called componentPtr. What componentPtr does is point to a member of Vector3D of the type float. Take a cue from its declaration syntax: note that the asterisk, indicating a pointer (or indirection), comes after “Vector3D::” in “float Vector3D::*componentPtr.” Take this to mean that it’s a pointer that can move within the space of the Vector3D:: scope.

Also take another clue from the initialization: it’s initialized to &Vector3D::x—the address of the x member in any Vector3D instance, not say, &v.x. So, when we use the pointer later, we need to specify which Vector3D instance it goes with: v.*componentPtr

Aside
I think of member pointers as offsets from the “this” pointers of instances. Imagine each instance as an instance of a packed POD (Plain Ol’Data) structure that contains two 32-bit floats, x then y, and a pointer to the structure points to its beginning. So, v.y would be the same thing as *reinterpret_cast<float *>(reinterpret_cast<uintptr_t>(&v) + sizeof(float)) and v.x would be *reinterpret_cast<float *>(&v). Indeed, that expression will work on most compilers (though you obviously shouldn’t use it).

Thus, I imagine componentPtr to be the “+ sizeof(float)” constant offset that marks how to use the object’s address to access the desired member. If you didn’t get any of the last two paragraphs, just pretend you didn’t read them, because it’s not too important.
End aside

So now you see how to use member pointers and how they work. But you’re probably thinking, “Xo, what the heck would compel any sane C++ programmer to use member pointers? In your last example, why couldn’t someone just use v.x and v.y instead of taking a pointer to them?”

Well first off, there aren’t really any sane C++ programmers. If you’re thinking that you could be an exception to this, you’re probably not sane or you might not be a C++ programmer. Maybe both.

Secondly, the idea behind them is that they’re variables. You use them the same way you would any other variable: to store results that you’ve computed or to pass data around. This means if you can boil down a long set of computations into a choice between members of a class, then you can avoid needing to compute it repeatedly and instead just pass a member pointer around.

Let’s see an example. We’re trying to write a function that takes in a std::vector of Vector3Ds and adds a float to a component of each one. Now, which component is determined at runtime, so we have to pass it as a parameter to the function:

void add(std::vector<Vector3D> & vs, int componentSelect, float amount) {
	for(std::vector<Vector3D>::iterator v_i = vs.begin() ; v_i != vs.end() ; v_i++) {
		switch(componentSelect) { // switch to determine which component to modify
		case 0:
			v_i->x += amount;
			break;
		case 1:
			v_i->y += amount;
			break;
		case 2:
			v_i->z += amount;
			break;
		default:
			break;
		}
	}
}

int main() {
	int componentSelect; // 0 means .x, 1 means .y, 2 means .z
	componentSelect = std::rand() % 3; // make a decision as to which one

	std::vector<Vector3D> vs(5, Vector3D(0, 2, 3)); // create five <0, 2, 3>s
	std::copy(vs.begin(), vs.end(), std::ostream_iterator<Vector3D>(std::cout, " "));
	std::cout << std::endl; // print out the list
	add(vs, componentSelect, 1.f); // add 1.f to a component of each Vector3D
	std::copy(vs.begin(), vs.end(), std::ostream_iterator<Vector3D>(std::cout, " "));
	std::cout << std::endl; // print out the list again

	return EXIT_SUCCESS;
}

Example output:

<0, 2, 3> <0, 2, 3> <0, 2, 3> <0, 2, 3> <0, 2, 3>
<0, 2, 4> <0, 2, 4> <0, 2, 4> <0, 2, 4> <0, 2, 4>

The above naïve way involves this int→Vector3D component conversion for each element in the container. This is slow and involves a lot of code copying & pasting. Moving the switch statement outside of the loop helps with the slow, but makes the code look even worse.

Member pointers to the rescue:

void add(std::vector<Vector3D> & vs, int componentSelect, float amount) {
	static float Vector3D::* const componentPtrs[3] = {&Vector3D::x, &Vector3D::y, &Vector3D::z};
	float Vector3D::*componentPtr = componentPtrs[componentSelect]; // select from array
	for(std::vector<Vector3D>::iterator v_i = vs.begin() ; v_i != vs.end() ; v_i++) {
		*v_i.*componentPtr += amount; // note: very little code duplication
	}
}

Now you see that we can use member pointers to store the result of the component selection (the switch statement) and then operate on data using this stored result.

Note that I used *v_i.*componentPtr += amount; instead of v_i->*componentPtr += amount;. This is because v_i is a STL iterator, not a Vector3D *. This is where you see the ->* operator (indirect .*) diverge from dereference-then-.*, as iterators do not need to define a ->* operator but do need to define a dereference (*) operator. If you really want to use ->* (and who doesn’t?), you’ll need to convert the iterator to a pointer first:

for(std::vector<Vector3D>::iterator v_i = vs.begin() ; v_i != vs.end() ; v_i++) {
	Vector3D *v = &*v_i;
	v->*componentPtr += amount; // note the use of ->*
}

This is isn’t even the only way we could have done this: there are also a few tricks with templates or STL components like <functional> we could have used to the same effect, with varying amounts of ease-of-use and compile-time vs. run-time flexibility.

This is just another example of the bewildering flexibility C++ offers between performance and code readability, or if you like, between compile-time code execution and run-time code execution.

Stay tuned for more “Strange C++.” In the next issue, we’ll discuss using member pointers to point to member functions, and how exactly using them will benefit our C++ applications.

You should read “C++’s .* and ->* operators: Part 2.”

1. Of course, this is not including the indirect versions of the latter two, -> and ->*

Every time I had my ID (and its affixed class schedule sticker) checked at the door, I made it a point to very obviously time the poor teacher doing his job with the stopwatch function on my Casio, and then record the time wasted by the check in a notebook I kept in my pocket. The following is the data I recorded:

Dates are recorded in October 2006 format; that is, the “day of month” is the number of days since September 30th, 2006. Days not in the table between 10/782/2006 and 10/830/2006 do not mean “not checked”—they mean that I didn’t eat lunch at the cafeteria on that day (I think).

As a warning, this post was useless, so those with time traveling capabilities will want to dial back 10 minutes to before they began reading this post.

My school was rather inclined to disagree with my petition for a “prerequisite override permit,” which is what I need in order to register for the C++ class, ECE 3090. After all, you couldn’t possibly learn C++ if you hadn’t first implemented some discrete FIR filters in the digital signal processing course first.

OK, just read my response after my registration permit was denied:

Hi Xxxxxxx,

But I will lose interest in schoolwork and begin to find my course-load irrelevant and tedious. Soon I will feel as if I have lost my way, and either turn to religion and/or become a Management major. Either path will only further my anxiety about my capabilities and self-worth, and soon my very existence will come into question. I will wonder if school is worth my time, or if life is even worth living.

Years later, as I lay on a desolate sidewalk, a vagabond stranded by the School of Electrical & Computer Engineering, tears will stream down my face onto my primary religious text and/or my diploma for my Management degree. It will be my last of many cold, lonely nights on that sidewalk. Hunger and sickness have taken its their final toll on my frame, already thin and abused since the second semester of Georgia Tech.

But as the world fades to darkness, I will realize that my tears are not of sadness, but of joy, joy that I had completed my core subjects instead of junior electives.

Oh, the humanities!

But seriously though: could I talk to the professor teaching the class next semester about getting a prerequisite override permit? I really am quite confident about the material in the course, and would like to take it to boost my GPA, and because I feel it is more relevant to my major as well as my interests and skill level overall.

Thank you,
Xo Wang
gtID: XXXXXXXXX

On Tue, 06 Apr 2010 09:59:59 -0300, Xxxxxxx Xxxx wrote:

ECE does not override prerequisites for its courses. Once you have
successfully completed ECE 2025, 2030, and 2040, you can take ECE 3090.
ECE 3090 is offered every Fall and Spring terms, and occasionally in the
Summer. You will have plenty of time to take it in the future. Right
now you need to concentrate on completing your core subjects, not junior
electives.

Regards,

Xxxxxxx X. Xxxx
Manager, Undergraduate Academic Advising
School of Electrical & Computing Engineering
Georgia Institute of Technology
PHONE: 404-894-XXXX
FAX: 404-894-XXXX

Below is the result of your feedback form. It was submitted by xxx@gatech.edu (ZHAO WANG) on Monday, April 05, 2010 at 19:18:02.

grad_ugrad: Undergraduate
term: Fall
GTID: ———
course: ECE3090
major: CMPE
graduation_term: Spring
graduation_year: 2013

comments: I already have knowledge of C++ and programming in 3090; previously held a job at a game graphics/AI company doing software engineering with C++.

The response I got was essentially a straight-faced “no” and “go have yourself a terrible @#$%ing day” only without those specific words and phrased a lot less politely. Yes, less politely.

By the way, I’m not actually a Management major now. I’m just going to be an EECS who leans towards CS rather than EE. And hates life.

Simply put, ray tracing’s generating computer images through a physical simulation of light, by “shooting” rays from a viewpoint in 3D space and then “tracing” them along their paths for objects to draw on screen. Shoot a lot of them and you will have enough information for the screen.

This is far superior in quality and correctness, though also very much less efficient, than our current method of rasterization: gathering up all the objects we put into the virtual space, deciding what they should look like given a few arbitrary parameters, and then drawing them on the screen where we think they should go. Ray tracers produce such good-looking images, in fact, because they are accurate.

For an example, see Wikipedia’s exemplar specimen of ray traced work:

If you need more convincing, check out a small company in California called Pixar. I believe they make these moving pictures or something.

“Now Xo,” you ask, “why did you call this wonderful ‘tray racing’ technique the ‘dark side’ of computer graphics? Surely it would be the ‘light side (no pun intended)?’”

No, it’s not. I learned rasterization first, I worked hard at some very pointless but very fast software rasterizers, and I just like it more. Shoot me (no pun intended).

Anyways, I wrote a simple “classical” (properly known as Whitted) ray tracer for CS3451² as an assignment. To my surprise, it took only eight hours of marathon coding to write, none of them daytime. The work consisted primarily of making and fixing simple mistakes that, once I had worked out the math, were physically incorrect.

That was the nice bit of it all; if you had a rendering error, you can just look at your model of the world and see if you did something in a way that makes no sense in the real world. Once I fixed those mistakes, I had a pretty nice ray tracer, if trivial by today’s standards.

These are the technical issues I stumbled on (and have stumbled on before; I don’t learn too well from my mistakes³), and ones you probably should watch out for:

• Normalize your unit vectors!
  Rays have directions representing their straight line path through space. These are usually represented with unit vectors. If you don’t keep them normal, then the distances you get through ray-object intersections will be inaccurate. This will cause issues if you actually depend on distances at some point, like when you do shadowing or light attenuation.
• Check for negative intersections!
  When checking for ray-object intersections. Make sure you discard intersections that are behind the rays origin. Say that you parameterize your ray as o + td, where o is the ray’s origin, d is the direction (uuunit veeector!), and t is the scalar parameter indicating distance along the path given by o and d. If you get an intersection of t < 0, discard the intersection.
  
  Don’t do this:
  
• Terminate your reflection rays by contribution!
  When doing lots of bounces around shiny objects, that is, objects of constant of reflection K_refl > 0, make sure to stop doing more bounces when additional bounces will contribute no visible difference to the image. My measuring stick here is by recursive descent along reflection rays: with each bounce, I multiply the contribution factor (which starts out at 1) by the K_refl of the intersected object. If the contribution of the next recursive level is less than 0.5/255, which is half the value of least significance for an 8-bit/channel output buffer, then I consider further bounces to be useless and terminate further recursion. It’s just a performance thing.
• Don’t let your reflection rays check against its own origin!
  When bouncing reflection rays, be sure to not check for intersections against the object you just bounced it off of. It’s a simple way to avoid a rendering artifact known as surface acne⁴. However, this technique will prevent objects from casting self shadows, which are exactly what they sound like. Therefore, omit the reflection intersection check for the biggest thing in an object that does not self-shadow, e.g. spheres, triangles, planar polygons, etc. So if you are reflecting off an object composed of many triangles, don’t intersect the reflection ray against the triangle it bounced off of, but do check against the other triangles in the object.
• Intersect your shadow rays with geometry and lights!
  OK, this is hard to describe, but it’s important. You check for shadowing by shooting a shadow ray towards the light you’re trying to err, check for shadowing against, right? If there is an intersection with another object, then there’s something blocking the light, right? Non monsieur! What if the light is between the two objects? For a shadow to be cast, the distance to the intersection must be less than the distance to the light.
  
  Example: There is a light smack dab in between two spheres. It should look like this:
  
  
  Except when it doesn’t:
  
  
  Just for the heck of it, let’s add more magic:
  

So there you have it. Hopefully the technical bits in this post will help some poor uni student out there struggling to race his/her first tray, the writing has entertained you, and at the very least the pretty pictures got you all excited.

1. Not meaning computers will get fast enough to simulate light realistically in real time; meaning they will make dining trays big enough to fit young adventurous men like myself
2. Computer Graphics at Georgia Tech
3. Unless I write it down with lots of parentheticals and footnotes like this
4. See this article: It’s Really Not a Rendering Bug, You see…

I once had an English teacher at Stuyvesant who insisted with utmost sincerity that the character Kurtz of Conrad’s Heart of Darkness was so named because of its supposed phonetic similarity to “Christ.” Furthermore, Okonkwo of Achebe’s Things Fall Apart has his name originate from our subconscious understanding of long, “masculine” vowel sounds. How could a syllable be masculine?

Her most far-fetched comparisons, which she dispensed daily with an unconquerable, belittling sneer, were the only ones which could match in tenuity to this little headdesk I was subjected to in junior year: “The jolly baker down the street has elected to use powdered sugar instead of granulated sugar. What do you think the author intended by such a decision fraught with between-the-lines intention?”

NOTHING. The author intended nothing!

So when I decided to create a new avatar for myself, my traumatizing experiences with English class led to me write the following disclaimer: “I intended my work to be experienced as it has been created. I enjoy the way it looks, and this work has no further meaning beyond its initial appearance.”

Then I looked at my new piece of work, the Outline:

Yes, I did make it the way it is because it looks nice. But it very obviously contains additionally meaning, much of it inherited from its sire, the Stuyvesant Techtonics (Stuy Tech/Techtie) logo (the Tech):

I wanted to retain the nature of my work, the hexagonal power button symbol that represents the melding of electronics and mechanics that is robotics. I discarded the dramatic red bar, standing out starkly against the black and white, because that was what Techtonics was when I made the logo—a bold sliver of a team, surrounded by uncreative soulless career-seekers. But I do not need such an iconoclastic representation; I’m a pretty quiet guy. Besides, taking out the red just makes it work better for my website. I removed the sharp caps in the bar and the five-sixths hexagon as well. Techtonics was an intense, competitive team; I am a person.

Of course, this means that I will be finally phasing out the remnants of my previous logo, the Indoor:

which has made its presence known only in its favicon form , which is now replaced with . The new logo resized surprisingly well.

Previous iterations of the Indoor have looked like so:

That last one is from 2003 or 2004. I believe I stole it from another website, because I remember it as originally animated. Please forgive me, other website. I was young, and you have done me a great service for the original art that has served me for so long. However, scioly.org, which is where I first began to use it, had and still has a very strict requirement on avatar file sizes, due to hosting costs. I cut all but one frame from it and simplified the palette. I eventually shaped the frame to look like my own planes, and animated the image once more to arrive at the final product, but I still wonder how the original looked…

Also, I found this amusingly terrible GIF bunched with the collection that the Indoor came from:

Wow. The things I did at the age of 13.

Now, you might ask, why do I need a personal logo? I really don’t. I don’t have that much of an ego to want a pictograph that represents me. The real issue was that I was using my Techtonics logo everywhere; my Gravatar, my chat services, my computer login, etc. It was my only work of art that was at all notable. In fact, it was my only work of art that could be said to be a work of art.

However, I didn’t agree with the new Techtonics leadership after I left and they took the team over. I took issue with their interpretation of the principles of Techtonics (which is that there are none), as well as the low priorities they placed upon the various activities Techtonics traditionally participated in. I didn’t want to be using the same logo that represented people with whom I disagreed.

And that is how I know I am not an English teacher. My little picture actually represents real live people now.

The real purpose of HJMP¹ (project page, GitHub page), which is what I’ve decided to call my new interpreter², is of course for me to play with JIT compilation on different platforms.

Now that recent versions of GCC are freely available on x86 and AMD64 versions of Linux and Windows³, we programmers can use the same tools and code and target different platforms with the minimum of changes (and headaches!). However, those differences do accentuate themselves if you begin working closer to the metal, either because of requirements like performance or just for fun.

In this case, the distinction causing trouble was calling conventions. Regular 32-bit machines use cdecl, which is straightforward and passes parameters to functions on the stack. Newer AMD64 software use variants of fastcall, which passes some number of arguments inside registers to take advantage of the doubled register count in AMD64 over x86. To make things more complicated, Microsoft uses their own unique AMD64 calling conventions for Windows and related tools.

Part of this exercise was to abstract away the general nastiness of writing—or generating—assembly code through object-oriented design. I accomplished this through the magic of dynamic⁴ polymorphism. Different code emitters generating code for each platform talked directly with AsmJit, the code generation library I used, but were hidden behind interfaces from the token processor. In addition, the token processors—one with JIT and one that executed token directly—were hidden from the parser (the token generator) as well through an interface, so that I can enable or disable JIT at runtime.

Overall, this little project was a success. It isn’t exactly groundbreaking or very useful for day-to-day work, but the experience of making it was a valuable one.

Download HJMP from the project page

1. pronounced “HIGH-JUMP”
2. in addition to “The Fastest HQ9+ Interpreter in the World”
3. under TDM GCC and MinGW-w64
4. and static too, really

Check it:

C’est la Z @ Blogspot

I saw fit to create a Dvorak version of US-International, with the same deadkeys and combinations, but with the three touch-type rows rearranged to fit ANSI Dvorak. It should be an easy switch for existing Dvorak users and great if you’re starting out learning Dvorak.

Keyboard layout installer for Windows 2000/XP/2003/Vista/7 (x86, x64, and Itanium): http://www.geekshavefeelings.com/files/keyboardLayouts/intldvrk.zip
Microsoft Keyboard Layout Creator source file: http://www.geekshavefeelings.com/files/keyboardLayouts/intldvrk.klc

The installer will add the layout to the Windows regional settings list of keyboard layouts, and is not some sort of driver, background service, or registry hack. It was made in Microsoft Keyboard Layout Creator.

Anyways, with the US-International keyboard layout, nobody should have any excuse to type “u” or “ue” instead of “ü,” “2 x 4″ instead of “2 × 4,” or “General Xo’s Chicken” instead of “General Xo’s Chicken.” Heck, maybe we could have prevented the creation of the English neologism “uber.”

Of course, I do take issue with its lack of distinction between the hyphen (-), the en dash (–), and the em dash (—), and its lack of the prime marks (′, ″, and ‴) and the ditto symbol (〃). However, its existing variety of punctuation, accents, and other typographical symbols, including separate key combinations for the single closing quote (’), the typewriter apostrophe (‘), and the acute accent (´), are easily enough to overwhelm the neophyte to ultra-elitist typographical pedantry (the sort I smugly enjoy).

Also, the dead keys themselves do get annoying. For example, Ubuntu Linux includes a layout called “USA International (AltGr dead keys).” That moves the dead keys to their AltGr combinations, so hitting the ‘ key would produce a ‘ straightaway, but to get the á (acute a) symbol, which is encountered far less frequently than the apostrophe, one would need to hit AltGr+’  and then A. Also of note is Ubuntu’s “USA Dvorak International,” which is not to be confused with my US-Internation Dvorak layout. It is simply the ANSI Dvorak layout with a few symbols available by AltGr; it is not, like my layout, a Dvorak remapping of the full US-International layout.

With that said, I’m not even a Dvorak typist. Heh.

Edit (10/1284/2006):
I did some extremely cursory Googling, and came up with these two more Dvorak layouts based on US-International (created by others):

• USID at Jargon File – Pretty much the same as my keyboard layout, except it came before mine. Update: it appears that the layout’s apostrophe deadkey produces an acute accent (´) instead of an apostrophe (‘); possibly other bugs as well.
• Dvorak international extended keyboard at Arjen van Kol – Instead of using an exactly key-to-key mapping from US-International to ANSI Dvorak, this layout moves many of the AltGr-accessed special characters to be adjacent to other similar characters.