Lock-in

Posted May 13, 2005 17:37 UTC (Fri) by jonabbey (subscriber, #2736) [Link]

I know of several portable GUI packages for C++. Take your pick. Likewise, communications support. Thread-safety is the norm in C++ libraries. One doesn't encounter pointers much, so "mistargeting" that "breaks encapsulation" (whatever that means) has never been a problem.

Do these GUI packages for C++ work on Mac (OS 9 and OS X), Linux, Windows, OS/2, AIX, etc.? We've run the Ganymede client on all of these systems, and more, without so much as a recompile.

By 'breaking encapsulation', I'm referring to the fact that, in Java, if I declare a variable private in a class, nothing outside of that class can ever touch it. It's impossible to craft a pointer to the private variable (on purpose or on accident), so it's impossible to read from it or write to it. There's no possibility of my encapsulation guarantees being violated. If that variable gets written, I know exactly where the code must be that did it. No chance of one portion of our large body of code accidentally scribbling on another portion, no matter how badly we try to screw things up in our human frailty.

I don't find myself worrying about "memory ordering" either. Fortunately, C++ offers much better than mere "Java-like" guarantees of memory management -- you get guarantees of general resource management that are impossible for Java to provide, even (or perhaps especially) with finalizers. No language can guarantee against failures, and no mere language can eliminate differences between operating systems. It is most fortunate that C++ lacks Java's "finally" clause: to my knowledge that is Java's greatest single failure. (Finalizers might be worse.) The whole point of exceptions is to allow error-handling code to be concentrated at choke points, minimized, and easily exercised. "Finally" clauses, instead, multiply it and distribute it throughout the program.

Yes, Java has poorly thought out finalizers. The rest of these statements are off-target. No, Java can't guarantee against the power plug being pulled, the CPU glitching, or memory being exhausted, but it can guarantee that everything else will result in catchable exceptions.

And finally is enormously useful, especially in multithreaded code, in that it can provide guarantees that execution will not leave a block without releasing locks, and so forth. Finally is not about enabling sloppy exception management, and the fact that you believe that to be the case shows that you don't know Java as well as you appear to know C++.

My code runs for months on end. If I have made a mistake and a thread runs into an exception condition, that thread unwinds, the exception is logged, and the Ganymede server just keeps going. No seg faults, ever. No buffer overruns. None of that. Not ever.

I expect Ganymede could have been written in C++ in much less time than it took in Java; I'd guess half.

Being the author of Ganymede and knowing its code rather well, I don't see how that could possibly be true. Definitely not ten years ago when it was first written. Today, perhaps, the design could be reworked in such a way that comparable functionality could be layered on top of a whole variety of independent libraries, frameworks, and external services, but to claim that we could get the portability as well as the reliability that we get with Java with a comparable effort in C++ seems wildly unlikely.