At this point, it was time to choose a production implementation language for OpenCM. I considered Java, but in spite of the hype Java really doesn't run everywhere, and I wanted to be sure that we could run our stuff on EROS someday. I looked at GCJ (a native-code Java Compiler), but the class library wasn't ready yet. For reasons that will become clear below, the decision not to use GCJ was a good one, because GCJ relies on the Boehm-Weiser conservative garbage collector.

I flirted briefly with C++, but decided not to use it for two reasons:

None of these was a good reason to avoid C++ as a language for OpenCM. Probably I was just burned out on C++ at the time. In any case, I allowed the scripting language issue to persuade me, and I decided to use C as the OpenCM implementation language. The C language decision forced us to hack together an exceptions package. Exception handling is one of those incredibly wonderful features. It substantially reduces the amount of code devoted to error checking, which clarifies everything. Unfortunately, it's only easy to use if the programmer doesn't have to explicitly manage the storage leak consequences. Exceptions are a real pain in the neck if you have to handle all the storage consequences yourself. This led us to look creatively at storage allocation.

One lesson from the Python and Scheme attempts did stick with me: garbage collection surely is convenient when it works. Some form of automatic storage management is essential when you are using exception handling in a system like OpenCM. We tried, in sequence, two collectors before giving up on the idea of garbage collection. Each failed us.

With a safer programming language in mind, we looked longingly at both Java and C#. I was eager to try C#, but I had users on a short fuse. While the C# runtime is well documented and relatively open, there are fast public implementations only for the x86 (the Mono project), and they were still too young to depend on for something as critical as source code control. This status has recently changed, and if I had it to do over, I might reconsider using Mono. One issue is that Mono uses the Boehm-Weiser collector, and we already knew that that wasn't working for us. The issues are a bit different, because Mono is in a position to make better use of the collector, but it's still a concern. Meanwhile, Java still had all the problems that concerned us originally.

So, with a great deal of trepidation, I chose C++ for the next attempt. This decision was motivated by three considerations:

The problem with the smart pointer assignment above is that the template mechanism is a lexical mechanism. The problem is that most smart pointer implementations define a naive assignment operator that looks something like:

template<class T>
class SmartPtr {
  ...
  inline SmartPtr&
  SmartPtr(const SmartPtr& other)
  {
    IncrementRefCount(other.pObject);
    DecrementRefCount(pObject); // mine
    pObject = other.pObject;
    return *this;
  }
};
	

Even though the object pointers embedded in aPtr and bPtr are assignment compatible, the two variables have different types, so the assignment fails to match the type signature of the assignment operator. Having figured this out the hard way, an excessively clever programmer (to wit, me) might say to themselves ``okay, what I need here is another template,'' and use the following assignment operator instead:

template<class T>
class SmartPtr {
  ...
  template<typename T2>
  inline SmartPtr& operator=(const SmartPtr<T2>& p)
  {
    // Following works around the fact that GCC doesn't
    // know how to do template friend declarations.
    T2* pOtherObject = &*p;

    IncrementRefCount(pOtherObject); // theirs
    DecrementRefCount(pObject); // mine

    pObject = pOtherObject;

    return *this;
  }
};
	

Given this definition of the assignment operator, the assignment statement:

aPtr = bPtr;
	

works as expected, and (equally important) the reverse assignment:

bPtr = aPtr;
	

Fails with a type violation.

So I implemented this trick for both the assignment operator and the SmartPtr from pointer constructor: This is the one that lets me write things like:

aPtr = new B;
	

Imagine my surprise when my program crashed while executing the destructor on a globally declared SmartPtr. It turned out that the target object had already been destroyed!

Fortunately the culprit smart pointer was (a) global, and (b) assigned in only one place. This made it pretty easy to find the offending line of code:

aPtr = new A;
	

Those of you who can figure out what is wrong without reading the rest of this note are truly experts of C++ obscurity. Given your evident level of skill, you should probably try to master the Pentium protection architecture next. For the rest of you who were as stumped as I was, read on.

Stepping through this code with a debugger, my first surprise was that a SmartPtr constructor was getting run. It turned out that I had ommitted the ``assign from pointer type'' operator, and the compiler was helping me by using the ``construct from pointer type'' constructor. It was a good thing I had, or I would never have detected the problem here. There is probably a lesson in there somewhere, but at the moment it escapes me.

The second problem was that this temporary SmartPtr was then destructed, reducing the reference count of hte newly allocated target object to zero and promptly destroying it.

The question: how was the variable aPtr getting set up in a way that later prompted a second destruct?

The answer: in converting the assignment operator to template form, I had accidentally eliminated the default assignment overload, which is absolutely necessary for SmartPtr. I looked at the two template form, decided that it would work fine when T2 matched T, and happily went on with my development.

Not so fast.

The C++ compiler only tries template expansion when it doesn't have an operator already defined. Because the class definition did not specify an overload of the default assignment operator, the compiler did have an assignment operator defined: the default ``copy by fields'' assignment operator that C++ inherited from the C language. Given the presence of this ``exact match'' assignment operator, there was no need to consider template expansion, and my template assignment never got consulted.

The solution was to keep both the original and the two template assignment operators. This solved the problem. The program now compiles and executes correctly (in its current, truncated form), and I can go on to work on other issues.

The first is that I'm still not sure whether this is a compiler bug or not. It's clear enough that in the absence of an assignment operator the compiler generates a fieldwise copy, but it's not clear (to me, at least) if a templated assignment operator should have been considered first.

I'm sure that some language lawyer can give us an authoritative answer, but it doesn't really matter. C++ violates the expectations of even expert programmers. This isn't the only area where this is so, but so far it's the most expensive one (in terms of time lost) that I've run into. It would be useful to have some tool that, given some input C++ code, would render explicit all of the operations that the compiler will do to it. Perhaps this could be implemented as a variant of the existing compiler, in which the output is a line by line explanation of how each line is compiled.

Programming languages should support rather than surprise. For C++ this is a daunting challenge because of the legacy burden that it carries. It's time to start shifting to cleaner languages.

In abstract, I'ld love to switch this code base over t oJava or C#. God knows we've rewritten it enough times that we should be able to do so with our eyes more or less closed. At the end of the day, though, Java remains a language without any conforming, open reference implementation or a publicly available, conforming class library.

C# is in much the same state, with the added burden that Microsoft will continue its ``embrace and extend'' policy by providing an ever growing pool of proprietary libraries that are ``must have'' if your application is to look and feel current. Perhaps it's time to consider creating a branding program for ``Open C#'' to indicate code that relies exclusively on open, publicly specified library interfaces that have portable licenses. I'm not looking for Open Source, necessarily (though that would be nice too). Rather, I'm looking for libraries that are implemented exclusively within the CLR framework and talk to a universally available UI toolkit. C# and CLR should become the next development target platform, letting us ignore the Windows vs. UNIX issue entirely.

The last lesson, I suppose, is that it's time to get back to work on OpenCM. I seem to have run out of insurmountable difficulties.