This is the tenth article in a twelve-part series that discusses the twelve finalists and their calculator submissions for the OMGWTF Programming Contest. The entries are being presented in the order submitted, and the winner will be announced on June 18, 2007.

There were a lot of entries that pushed the limits of C and C++: self destroying objects, self-modifying code, you name it, someone probably did it. Entries like this introduced a whole new level of convolution that leads to a progression of reactions: “… huh!?... is that doing what I think it is!?... who would even think of that!?... why would they even /allow/ that!?... huh!?” Within this category, we felt that Entry #100265 (Dennis Ferron’s FerronCalc) was the most ridiculous and most complete.

First, let’s start off with a diagram:

I know what you’re thinking: Hey! That’s just a state diagram, what’s that have to C++ abuse! Simply put, the FerronCalc state machine is based entirely on C++ templates.

Typically, the state machine design pattern is implemented by having a wrapper class pass function calls to whichever state object that state the machine is in. A phrase used to describe this pattern is, quote, “the object (the wrapper) appears to change its type as its state changes.” In other words, the wrapper acts like a chameleon and impersonates different behaviors for each state.

Instead of the FerronCalc’s state machine wrapping state objects, it uses multiple-inheritance to derive from every state it can exhibit.

Normally, this would be a slight problem: if a class inherits two classes that define the same method (“foo()”), that method may only be called by casting to the parent class (“parent1->foo()” or “parent2->”foo()”). Dennis was able to “solve” this “problem” with the magic of templates: by simply passing in type T, the compiler can resolve the desired call without any ambiguity. Of course, since templates are handled at compile time, this is really a doubly-overengineered exercise: the template calls merely become a proxy for the wrapper for the state machine.

Furthering down the road of template abuse, FerronCalc utilizes a separate class for each number. Not quite as how you might think: the value of a number is calculated according to its prime factors. For example, the class Ten is defined as Two times Five. The following code explains it best…

 

class Zero	: public Number<0> {};                    
class One	: public Number<1>, public After<Zero> {};  // It may surprise you to know
class Two	: public Prime<2>, public After<One> {};    // that I really hate Math.
class Three	: public Prime<3>, public After<Two> {};    // (But I sure love numbers!)
class Four	: public Factors<Two, Two>, public After<Three> {};
class Five      : public Prime<5>,                  public After<Four>      {};  // See, aren't these nice?
class Six       : public Factors<Two, Three>,       public After<Five>      {};  // Why do mathematicians have to
class Seven     : public Prime<7>,                  public After<Six>       {};  // come along and muck up my beautiful 
class Eight     : public Factors<Two, Two, Two>,    public After<Seven>     {};  // integers with their algebra and
class Nine      : public Factors<Three, Three>,     public After<Eight>     {};  // calculus and irrational numbers?
class Ten       : public Factors<Two, Five>,        public After<Nine>      {};  
… snip …
class NinetyOne     : public Factors<Seven, Thirteen>, public After<Ninety> {};
class NinetyTwo     : public Factors<Two, Two, TwentyThree>, public After<NinetyOne> {};
class NinetyThree   : public Factors<Three, ThirtyOne>, public After<NinetyTwo> {};
class NinetyFour    : public Factors<Two, FortySeven>, public After<NinetyThree> {};
class NinetyFive    : public Factors<Five, Ninteen>, public After<NinetyFour> {};
class NinetySix     : public Factors<Two, Two, Factors<Two, Two, Seven> >, public After<NinetyFive> {};
class NinetySeven   : public Prime<97>, public After<NinetySix> {};
class NinetyEight   : public Factors<Two, Seven, Seven>, public After<NinetySeven> {};
class NinetyNine   : public Factors<Three, Three, Eleven>, public After<NinetyEight> {};

All numbers larger than ninety nine are stored as a tree of products. For example, 357 becomes ((3 * 10) + 5) * 10) + 7. This strategy also allows for certain recursive functions to exploit the inheritance tree.

One piece about the FerronCalc that I found particular entertaining was the “Greedy Garbage Collector.” It was implemented on class Object (the base-class-of-all-base-classes) and works manually: the user has to click the “C” button to initiate garbage collection.

There are also some interesting facts about Dennis Ferron as well. His first computer was an old 8-bit Z80 (256K of RAM) that could only run CP/M. At the time, everyone else was rocking Windows 95 on their Pentium computers.

Dennis is also a Marine. I mean the real kind, not the huge-aficionado-of-Doom kind. He honorably discharged a few years back and is currently finishing up his undergraduate degree at Southwestern Oklahoma State University.

And believe it or not, Dennis would actually use FerronCalc in place of Windows Caluclator:

Absolutely, I would. During the testing of my program, I compared my program's results to the results calc.exe produces. In the process I found an obscure bug which calc.exe has but which my program does NOT! Yes, the Windows calculator is buggier than a WTF entry. You heard it from me first.

Download Entry #100266, FerronCalc (ZIP File)

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!