Category Archives: Code

How to Statically Initialize Arrays with Arbitrary Values

[Warning: Low-level C stuff ahead!]

Imagine a situation where you want to statically initialize an array with values different to 0:

This approach works, at least until someday you want to increase the array size to, say, 200. In this case, you have to add 192 times “42, ” to the initializer list. What a dread!

Everything would be easy, if you wanted to zero-initialize the array:

With zero-initialization, all you have to do is specify the value of the first element – all of the remaining elements will automatically be set to zero.

But sometimes you need a value different to 0 and you don’t want an additional call to “memset()” at run-time. Or you cannot use “memset()” because your array is stored in a read-only ROM segment and you cannot change the array’s values dynamically.

Basically, what you want is this:

Then, you would only have to make a single change to alter the size of the array (or the initialization value).

Alas, it turns out that it is impossible to define a macro that does the job we expect from “STATIC_INIT”. Think about it for a while. How would you solve this problem?

Sometimes, it is possible to replace a call to an impossible macro with the inclusion of a header file; I call this technique the “Replace macro call with file inclusion” trick:

The two defines represent the macro parameters and the inclusion of the header file represents the actual macro call.

You probably wonder what the contents of “static_init.h” are, but it’s instructive to spend some time on this problem yourself. Afterwards, you can have a look at my solution.

Note that this approach is not limited to single values – you can also use it for more complex initializations. For instance, if you need an alternating sequence of ’42’ and ’13’ you would do this:

I’ve also used the “Replace macro call with file inclusion” trick to encapsulate #pragmas and other compiler-specific features. Consider the case where you are working on a multi-platform project that uses different compilers. Consider further that you have a piece of code that generates compiler warnings and you want to locally turn compiler warnings off:

Now the problem with this approach is that #pragmas are compiler-dependent, which means that you will end up with something like this:

Not only does this litter the code – it is also a maintenance nightmare.

Usually, the solution is to encapsulate compiler specific features in #defines; alas this obvious strategy doesn’t work for #pragmas:

So it is time to roll out our trick once again:

Where, for instance, “warnings_off” looks like this:

You probably won’t need this trick very often, but when you do, it is good to know that it’s there.

The Awful Java Programming Language

In 1880, Mark Twain wrote a satirical essay entitled “The Awful German Language” where he explains his difficulty in getting the hang of the complicated German grammar. Today, I felt like it was time for me to nag a little bit about the Java programming language.

Don’t get wrong – I’m actually a Java fan. Years ago, I took (and successfully passed) the “Java Certified Developer” exam; I’ve written a considerable amount of Java code in my life. I’ve always loved Java for its run-time environment: the platform-independence you get from the virtual machine and the huge set of powerful libraries. I’m not complaining about Java per se – I’m only complaining about the Java programming language.

Obviously, it’s easy to find weak spots in any programming language – that’s why there are so many of them. Today, I only want to focus on one thing – Java’s wordiness, or rather, Java’s lack of expressiveness.

When developing software, I often start out with a Perl prototype. Yes, Perl is a quirky language, but it is also very powerful and most of its power comes from its very expressive grammar. It is easy to get your job done with Perl.

The other day, I was working on a seemingly simple problem, along these lines: a server produces a text file, containing user vs. usage-time records:

Another process – my program – takes this list as input, sums up all the usage-times for a user and prints an alphabetically sorted list:

That’s it. Sounds like a five minute job, which it is, if you happen to use Perl:

But since I needed this functionality as part of a larger Java product, I bravely recoded it in Java:

Wow! I used the regular expression library and the HashMap container class; I even used Java 5’s autoboxing feature as well as generic containers (both of which save you a lot of casting); nevertheless, the Java version is more than four times longer than the Perl script. Here are the stats:

Is this additional typing really such a big problem? It definitely is! Studies have shown that the number of lines written per developer per time-unit is by and large independent of the programming language used, which means that you are three to four times more productive in Perl than you are in Java. But there is another angle to this problem: if your programming language is highly expressive (like Perl, Python, and Ruby) you are many times more likely to actually write programs. You cannot imagine how many useful programs I have written in Perl that I would have never written in C/C++/Java – just because of all that typing!

I’ve never liked Sun’s “it-is-so-simple-even-a-brain-dead-monkey-can-now-program” paradigm. As a professional software developer – just like a craftsman – I need powerful tools: tools that get the job done in as little time as possible. These tools might be dangerous – very much like a power drill or a circular saw – but in the hands of an expert they can achieve miracles.

But Perl is not perfect, either. In my view, it is good for short programs, less than 1000 lines of code. For larger projects (possibly involving more than one developer) statically typed languages — like Java — are probably a better choice.