For the first time since learning Java, I wish I was doing C++

I started doing C++ back just before cfront 2.0 just came out. For those of you not paying attention, cfront was a program that turned C++ code into C code, and then fed that into the C compiler. There wasn’t any such thing as native C++ compiler, or C++-aware debuggers. It was “fun”, especially when you got a core dump and you had to read a symbol like “foo_vt0_bar_xyzzy” and figure out that this meant that it had something to do with a virtual method in foo called something like bar. And of course, the line numbers in the backtrace were no help at all because the generated code bore little resemblance to what you’d written. Cfront 2.0 was when multiple inheritance was first introduced into C++, and I think it was around 1989 or so. I know I went to Usenix in Baltimore a few months later to take a class in C++ from Stanley Lippman, who’d written a book whose title he’d insisted on pronouncing as if the word “primer” was derived from “prim” rather than “prime”.

When Java came out, I thought it was a great improvement on C++. No more worrying about whether you’re responsible for destroying an object or if that’s done at a different level, no more pointers versus references, etc. Plus it had a much more complete API (the C++ Standard Template Library came after the last time I did C++).

But a few days ago I found myself wishing we had one feature from C++ in Java. In one C++ job I had, the code was littered with what appeared to be unused local variables of a certain class. It was never assigned to, never read from, never even mentioned after the first line of the method. But if I took them out, things started breaking. So I did some investigating, and found that the constructor for that class would grab a synchronization lock, and the destructor would release it. At the time I thought it was a bit of a Jedi Mind Trick, and probably not good programming practice because it wasn’t immediately obvious what was going on to a new developer.

Now Java has synchronization locks built in, so I don’t need to copy that idea, but I am doing something similar. I’m currently modifying our code, which up until now has used a global “Connection” variable to keep only one connection to the database open for the life of the program, to use a pool of database connections so that we can turn off “autocommit” and use transactions. So I’m going around modifying dozens of methods to start with

DatabaseHandle handle = DatabaseConnectionPool.getHandle();

and to end with

DatabaseConnectionPool.returnHandle(handle);

And I’m thinking how much easier it would be to have a local class object whose constructor got a handle from the pool, and whose destructor returned the handle to the pool. Yeah, I could do the “get a handle from the pool” in the DatabaseHandle constructor, and have a method in DatabaseHandle to call at the end to return it, but it still wouldn’t be as neat as a simple local variable definition. So no Jedi Mind Tricks for me.