I’ve been making some major ACCELA changes in the past few days.

The first was something that’s been bothering me for a while: that extra flag in the XRefCounter and XWrapper class templates. Flags are often a sign of sub-optimal design. They can be hard to read because “true” and “false” don’t have enough inherent meaning. A better approach is usually to add more meaning to whatever the flag accompanies, so that’s what I did in this case.

I created new simple wrapper types that contain a reference type - like a WindowRef - with the additional meaning that “this reference has just been retained” or “you should delete this object when you’re done”. XRefCounter and XWrapper now have two constructors: one that takes the plain reference type (the WindowRef), and another that takes the “retained” or “owned” wrapper type.

This actually has two advantages. First, it replaces those flags with something that’s easier to read. Second, any function that returns a newly retained or created reference can return the new retained/owned wrapper instead so that you don’t have to remember that detail when you use the function. That information is already built-in.

This kind of thing is what I love about C++.

Since this was such a wide-reaching change, I also started writing some basic unit tests. So far I had only done that for the document classes. To begin with I just have some tests for ACFString, but that tests the new wrapper class system well enough too.

That new unit test project (BasicTests) includes every file in the library, to make sure everything complies. It also has a file that includes every header file that doesn’t have a corresponding source file, to make sure the compiler looks at everything. This uncovered quite a few problems. There were several files that I had written speculatively but never used. In some cases I had written the same class in different places, and the compiler complained about reusing the name. Right now I have everything compiling except for the duplicate printing classes.

Now I’m working on a new approach to Carbon Event parameters, associating them with their type codes and data types. Instead of manually adding new entries in AEventParameter.h, I developed some regular expressions for extracting the definitions from the Carbon header files and turning them into macros that declare template specializations. Most parameter names are followed by a comment with their type code, and most type codes have a comment with their data type. I still had to do some hand-editing for the exceptions, and for those which didn’t have one specific data type, but it’s still more efficient than the old way.

This is another thing that makes C++ fun for me.

On the other hand, there are many of you who might not see how any of the above could be called “fun”. To each his own. I’m going to go home and watch cartoons.