Java to C++

4 ^PM March 18, 2004

Apropos Charles’s recent post on C++ and its relationship with Java, here are some notes from my recent, three month stint in C++.

From a technical point of view, the application we were working on was very simple: single user, two-tier design, green-fields development. As a result we side-stepped a lot of the truly interesting C++ problems, such as needing to implement half a garbage collecting memory manager.

Like Riding a Bike. I was surprised just how much C++ my brain had retained. I'm a bit annoyed too; I could be using that memory-space for something else.
I think I know why Joel doesn't use exceptions in C++. There are three main ways of indicating exceptional conditions in C++: through the global errno, through a return code and through exceptions. The three styles don't mix well at all -- you need to pick one and use it consistently.
The Windows API uses return codes, so it makes sense to use return codes when programming C++ on Windows. In our case, we weren’t using Windows, but the client was more comfortable with the return codes than exceptions, so that’s what we used.

Exceptions work well in Java because they are the single, standard way of indicating exceptional conditions, it therefore makes sense to use Exceptions in Java. I can only guess that the reason Joel doesn’t use exceptions in Java is that he is so used to the return-code style.

const is a major PITA. const is one of those ideas that is good in theory, but horrid in practice. The main problem for us was that if one bit of the code is made "const correct":http://www.cis.nctu.edu.tw/chinese/doc/research/c++/C++FAQ-English/const-correctness.html#faq-18.1, all the code around it is "sucked into the const vortex":http://www.cis.nctu.edu.tw/chinese/doc/research/c++/C++FAQ-English/const-correctness.html#faq-18.3.
After a co-worker decided const-correctness was a Good Thing™, I spent several afternoons retrofitting consts all over the codebase. Those afternoons went like this: add a const keyword. Recompile. Find the newly caused const errors. Add another const keyword. Recompile. See one hundred new const errors. Decide a strategic cast of const to non-const might be appropriate. Repeat.¹

To be fair, it became less of an issue over the period of a month or so as the consts wormed their way through the codebase. Even so, I don’t think const-ing caught a single error, or helped us write code any faster. Watch Scott Meyer shuffle his feet when Bill Venner puts this to him.

One of the best decisions James Gosling made was to hold off on adding const to Java.

Garbage Collection is Good. There were just a few occasions when it was necessary to carefully think through who-is-responsible-for-deleting-what questions. Each time, I was reminded of just how useful garbage collection is.
I Modified the Literal Empty String. As in "". "I broke it":http://www.cardboard.nu/archives/000243.html. Seriously! It took four hours to figure out what was going on. Yay for Java immutable strings.
The Standard Template Library was useful. Good to see that Java will get Generics soon.
Long Compiles Are Good for Blogging. If one were to change certain important header files, one could expect a twenty minute compile, on a good day. Makes me appreciate Java's support for incremental compilation.

This all serves to confirm Java’s credentials for winning over C++ programmers.

¹ Actually I used a bit more thought than that, but that’s the general strategy. Next time I won’t whinge. I’ll just do this:

$ find . -name ’.cpp’ -o -name ’.h’ | xargs perl -i -p -e ‘s/const//’

$ cvs commit -m ‘fix compilation errors’

By alang | # | Comments (3)

(Posted to Software Development)

Comments

At 17:17, 18 Mar 2004 jed wrote:

you think String is immutable?

    public String getAString() {
        //get a reference to the private field value in String class.
        java.lang.reflect.Field stringValue = String.class.getDeclaredField("value");
        //make it accessible
        stringValue.setAccessible(true);
        //unsuspecting string 
        String sittingDuck = "sittingDuck!!!!!";
        //black magic happening here
        stringValue.set(sittingDuck, "hastaLaVistaBaby".toCharArray());
        //guess the output of this!
        return "sittingDuck!!!!!";
    }

(#)

At 21:06, 18 Mar 2004 Alan Green wrote:

Heh. Even so, this is one case where C++ is easier to understand than Java:

char *p = "sittingDuck!!!!";
strcpy(p, "hastaLaVistaBaby");
return "sittingDuck!!!!";

(#)

At 21:15, 20 Mar 2004 Andrew Reid wrote:

There's another reason to avoid exceptions in C++: You have to target a compiler that implements them poorly, if at all (like the '95 vintage Solaris 2.6 x86 compiler (grumble grumble)).

These restrictions can lead to the absurd state of affairs where the "use of string and collection classes is deprecated" to support legacy compilers.

Think not having GC introduces pointless bugs? Try going back to strcpy() and char* strBuf = malloc(BUFSIZ+1) and see how you like it :(

(#)