A Good Imagination and a Pile of Junk

I brought my unfinished sudoku solver code out of retirement as a chop builder this past weekend.

I was noodling around with it, primarily adding test cases (as I hadn’t worked on it since I’d built my C++ unit testing framework) and surveying the state of the code.

I was struck by how overengineered it was. Classes and objects flying all over the place. Sure, methods were relatively small (after some banging around) and to the point. But the whole thing seemed pretty damn overwrought, with an awful lot of the code being designed around managing the code.

It occurred to me that the couple/few algorithms were buried in this structural schlock, removing any possibility of elegance.

So I thought to myself I thought “self? YOU need to prove that you actually know how to program.

The best way I know to do that is by being forced to get rid of all that crap.

I’ve decided to go back to C. It’s the only way I’ll be able sure I’m not just hiding behind abstraction layers.

And so yesterday I kicked off a project with the simplest of makefiles, my testloop script and “main.c”.

It took some wrangling to get started (do I want to represent a sudoku board as char[9][9]? Or just as char[82]?) But once I’d proven that I could parse and serialize the boards (making creation of test cases a breeze) I was off to the races.

Two or three simple functions on top of that and most simple to easy boards were solved.

The wisdom of the approach became clear when I realized that I spent 20 minutes unable to determine why:

sprintf("[%s]\n”,serialized_board);

segv’ed all over the place.

Looking forward to finally getting my C legs back.

Today I’m focusing on cleaning up the code and documentation to my C++ Unit Testing Library with the goal of blasting the 0.1 up to sourceforge tonight sometime.

I think what I’m going to do is give myself a 18:00 deadline and put up whatever I’ve got and call it 0.1. Otherwise I’ll padiddle with it for six more months, all the while bitching that it’s not ready for public consumption.

The stuff I’ve decided to agonize over:

- Licensing.
- Name.

The stuff that decided it was going to be agonized over whether I liked it or not:

- graphviz & dot, as usual.

UPDATE: Alright. Done fighting with graphviz and dot. Conclusion: doxygen docs, as much as I love them, will have to wait for a subsequent release. I can’t yak shave myself into paralysis on this.

UPDATE: Ok, or maybe what I’ll do is spend all night cleaning up the damn code.

This afternoon I punched through a major wall (a couple posts down) that was preventing me from doing what I wanted to do here. I’ve been working (at about a 33% pace, what with all the hippy taunting and such I’ve been doing. It IS Saturday Night after all.)

The goal is in sight. I may very well be able to simplify this some more. But here, WITHOUT MACRO MAGIC is the first “live use case” of my C++ unit testing framework.

void test_test()
{
assertEqual("Hello World!","Hello World!");
}
protected:
virtual void register_tests()
{
register_test("test_test",&MyTestSuite::test_test);
}
};


The goal, more clearly stated is to be able to create an xUnit test class with “simple as possible” method tests. C++ being C++ means you must intentionally register the methods themselves.

Yes, the register method is messier than I’d like. I could get rid of the “test_test” parameter by using RTTI but frankly, the farther I can get without opening that can of worms, the better.

Yes, the constructor is a bit messier than I’d like. Currently it’s “the easiest thing that does the trick.”

People who understand C++ will at least get why I’m doing all those things.

Now, more cleanup, more of the framework’s unit tests migrated into the new suite architecture and a few more bits of functionality.

The goal is a production-ready release on April 1, with documentation, etc.

Oh yeah, the library’s about 10k spread across 2 header files.

WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?! WHY!?!

WHY won’t this work! WHY!?!

MONTHS this has been holding me up. It looks so damn simple!

If I replace “AtomicType” with just about anything, including std::string, it runs like a charm.

Something is wrong with the fact that it doesn’t know what AtomicType is at compile time. But that’s not a bug in the source.

MONTHS this has been holding me up.

ANYBODY!?!

*bangs head on desk*

UPDATE:w00t! Here we go: “While trying to show that it didn’t matter if I instantiated the damn thing” hmmpf…

Seriously though. I added 2 lines to main to create a Bar with an int template, then to call “foobar()” on that object.

While that worked fine and didn’t have anything to do with the problem, it DID give the compiler enough information to give me a more detailed error message (which is a g++ fail IMNSHO.)

The error it yielded was:

dependent-name ‘PretendContainer::InternalType’ is parsed as a non-type, but instantiation yields a type
scrapyard.cpp:21: note: say ‘typename PretendContainer::InternalType’ if a type is meant

Now that makes perfect sense. So changing the offending line to:

typename PretendContainer<AtomicType&gt::InternalType i;

fixes everything.

So it seems that while everything I was doing was right and legal, the compiler was experiencing a bit too much indirection to adequately intuit what I meant, so it needed the “hint” of an explicit “typename” modifier.

Makes sense, though I can’t say as I’ve ever run in to this before. It’s JUST odd enough that it’s been outside my experience. Which is pretty odd because I’ve seen (and pumped out) a LOT of c++ code in my day.

So now my night is committed to my C++ Unit Testing Library.

(and maybe some WoW)

Check this out:

 1: template <class T_>
 2: class SimpleTemplated
 3: {
 4: public:
 5:   T_ i;
 6: };
 7:
 8: template <class T_>
 9: class Container
10: {
11: public:
12:   typedef SimpleTemplated<T_> Composite;
13:   typedef std::list<Composite> Collection;
14:   Collection l;
15:   void run()
16:   {
17:     Collection::iterator iter;
18:   }
19: };

Here’s the pretty colorized version

Line 17 fails compilation (g++, cygwin, vista) saying

scrapyard.cpp: In member function 'void Container<T_>::run()':
scrapyard.cpp:17: error: expected `;' before 'iter'
make: *** [scrapyard.o] Error 1

Anyone? ANYone?

If I change line 12 from:

12:   typedef SimpleTemplated<T_> Composite;

to

12:   typedef std::string Composite;

it works fine of course.

It’s not a direct issue with the stl collection class either. I’ve also tried vector, as well as attempting creation of const_iterator and size_type, all with the same result.

Something about the SimpleTemplated template class is preventing me from declaring a var of a type defined within the containing collection class instantiation.

Pulling my hair out. (This is what happens when I come back to c++ after a year or two off and try something like this first thing. *ugh*)

My brain hurts now. But this works:

template <class T_>
class Base
{
public:
typedef void (T_::* TestFunc)();

int main()
{
Child c;
c.Go();
}

It’s the keystone of an important part of what I want my C++ unit testing library to do.

I tried having Base::run_it use the implicit ‘this’ pointer instead of needing the T_ parameter, but it pukes all over the place. I may try hitting it with a bigger hammer, play some casting games and see if I can do it without rending the fabric of the space time continuum asunder.

I has teh dubm nows.

UPDATE: Why it switched fonts in the middle there I’ve no idea.

UPDATE: Once my brain recharged I realized that since I have the T_ type in the base class I CAN use the “this” pointer by explicitly casting it. Passing “this” into the base class constructor is pretty stupid.

I’ve dusted off my C++ unit testing framework as it’s been a bit underfeatured for use on a couple projects I’ve been working on.

The fun part is that it’s the ultimate TDD dogfooding project as I’m oscillating between the tests and the framework itself as it evolves.

Frankly I don’t consider what I’m doing to be re-inventing the wheel. Every C++ unit test framework I’ve tried has thwarted me in some way or another; most frequently in the name of making it easy to add a test via macro-magic.

I just don’t care so much about that. I can type. Besides, the result of having ‘the simplest possible add_test line’ is usually a bunch of crap in the test framework that I just cannot in good conscience abide. Hey, if that’s your goal… awesome. Rock on with your bad self.

If I wanted everything to be a one-liner, I wouldn’t be using C++ in the first place.

My real goal with this is to have a framework that’s as rich as reasonable while using standard C++ (requiring a mature compiler. It’s 2009 for chrissakes, you need to support the language) and keeping the framework to a couple (at most) header files. That’s it. There shouldn’t be anything to getting the framework in to place besides:

#include “testfw.h”

and including your test driver shell.

So we’ll see. It’s ambitious of me to try and simplify this down that far I know. But I’ve only got a couple problems left to solve before I’ll have something worth sharing. HOPEfully I’ll maintain the requisite steam to get that out in a few hours. But I’ve an awful lot to work on today.

It’s going to be a bit before it’s got a nice spit-shine on it. But in the meantime…

UPDATE: 7 hours later I have a reasonable TestSuite class. I’m pretty surprised that there are less than 30 unit tests for it which really cover the thing pretty well. I have yet to add recursive suite support (suite of suites.) And I need to templatize my assert functions, they’re stupid the way they are. But it’s more than serviceable at the moment. Definitely not the worst code I’ve ever written.

I’m spent.

Mocking out native gui control classes for testing is a righteous pain in my ass.

I’m just sayin’ yo.

By looking at my last half dozen posts it oughta be clear that I’ve got something in the pipe. It’s not going to set the world on fire, but it is going to put a stone on the ground I can stand on to help me reach the torch.

But I find it nigh imPOSSIBLE to write software when it’s light out.

It’s always been true.

I try all the environmental tricks. I put on the Buddha Bar playlist (great for working to.)

But now matter what I try it’s as though I’m uberADD during the day. I’ve been forcing the issue this weekend, which is tough. But I have to get this application to the DogfoodStage soon or it simply won’t have enough momentum behind it and it’ll be relegated to the boneyard like so much else.

When doing TestDrivenDevelopment with your own homebrew xUnit test framework that uses extensive exception handling for test failures, don’t flip out when, while running the test app in the debugger, the debugger breaks a nail screaming about thrown exceptions.

Then definitely do NOT spend a half hour looking for errors in the library code.

I’m just sayin’ yo.

Well it’s good for a yuck anyway.

I’m glad I’m working on this project. My chops are clearly still there, but I’ve forgotten so much of the plain old stupid shit that just happens.

I don’t know how far I’m going to get on this project over this weekend, since I’m at least as likely as not to see something shiny. So I’m not going to start pumping it up yet.

I’ve been cruising along developing this app in Borland’s C++ Builder when I ran into the strangest stumbling block.

When I open an ofstream in the test application like so:

std::ofstream outFile(”foo.bar”);

everything works just duckiliciously.

However, when I execute the same line of code within the context of a gui app’s menu save event trigger, I get a huge explosion.

Over the last 45 minutes I’ve been back and forth, tracing it through and I’ve come down to a problem with the locale. the getloc() method in std::ios_base (which is just returning a dereferenced _Ploc) is crapping out all over the place, as if the default _Ctype doesn’t exist in the context of the gui app.

Is there some kind of standard library initialization that’s going on in the console app that isn’t going on in the gui? I’ve been pouring over the build and link options and everything SEEMS ok. But I have to be missing something.

“Oh yeah, development’s going great. I mean, aside from the fact that I can’t get it to SAVE” doesn’t work.

As a goof, here’s the stack:

std::ios_base::getloc(this=:0012FB48)
std::basic_ios >::widen(this=:0012FB48, _Byte=’ ‘)
std::basic_ios >::init(this=:0012FB48, _Strbuf=:0012FAF0, _Isstd=false)
std::basic_ostream >::basic_ostream >(this=:0012FAE8, _Strbuf=:0012FAF0, _Isstd=false)
std::basic_ofstream >::basic_ofstream >(this=:0012FAE8, _Filename=:004071F6, _Mode=2, _Prot=438)

UPDATE: Well I’ll never run in to this problem again, so I’ll put the answer here just in case I’m wrong about that too.

The call to the std::ofstream constructor in the gui app was taking place inside a dependent library that had options incompatible with the gui application itself, but not with the console application. So in one case it was using the correct (read: matched) ctype and locale information and in the other case it wasn’t.

Pulling it out of the library (where frankly it didn’t really belong anyway, I was prematurely optimizing) into the main project worked just duckiliciously.

I’ll bet you all were really worried huh?

Good christ this stuff is a headache. Perl has this wonderful module that allows you to build simple xmlrpc clients and servers very easily.

It looks at the structure of your request and figures out by the data type how to map it in to xml by playing data type guessing games.

Unless you pass it a date, which it treats as a string.

Now, xmlrpc has an explicit date type. So if you’re using XMLRPC::Lite to call an api method (for instance metaweblog.newPost) and pass it a date in the request structure (say, in the ‘dateCreated’ or ‘date_created_gmt’ fields), what the server gets isn’t the date field, it’s a string field, even though the contents are the same.

How to force it to call the thing a date I have no idea.
Currently I’m looking at rewriting the damn client in python.

But my eyes keep sliding over to my old (but pretty damn robust) c++ xmlrpc libraries. I could use that to generate a request and, if I was feeling lazy, just pipe the thing into curl or wget.