The lone C++ coder's blog

The blog has moved to a new URL

nospam@example.com (Timo Geusch) — 2010-07-21T15:09:15Z

Dear readers, I'm almost back in the blogosphere as a producer rather than as a consumer. Heck, if Steve Yegge can come back, I might give it a try as well .

I've taken the opportunity of moving the blog to its own domain, cunningly called www.lonecpluspluscoder.com. This "old" blog will stay up, at least as long as the server it is on stays online, but I won't be adding any new content here. Please head over to the new blog and subscribe to its feed.

A neater way of handling common exceptions

nospam@example.com (Timo Geusch) — 2010-02-04T21:38:00Z

In a sense, this post is a follow-up to the "little exception shop of horrors" below. I believe the idea with dumping all the exception handling code into a header file was to avoid code duplication. No, I didn't write that code - I inherited it, which was bad enough. Sound idea but bad execution, plus of course you still have code duplication as the preprocessor will do the work for you. Ah well, at least to don't have to type the code in yourself multiple times. I couldn't help but think that there must be a better way.

Continue reading "A neater way of handling common exceptions"

Building cedet on Windows

nospam@example.com (Timo Geusch) — 2010-01-27T12:49:06Z

When building both cedet-1.0pre4 and -pre6 on Windows with cygwin and a fairly recent emacs 23.1-based Emacs-W32, a whole boatload of errors suddenly disappear when you make the following changes:

in Makefile, change "EMACS=emacs" to "EMACS=runemacs"
For good measure, also set "SHELL=bash", which is usually commented out

It goes without saying that it's a really good idea to disable any Cygwin version of emacs if you want to use Emacs-W32, too.

The homebuilt NAS/home server, revisited

nospam@example.com (Timo Geusch) — 2009-12-23T14:33:08Z

I've blogged building my own NAS/home server before, see here, here, here and here.

After a few months, I think it might be time for a little interim update.

Unfortunately in its original incarnation, the server wasn't as stable as it should have been given my previous experience of FreeBSD. For some reason, it would crash every few weeks and sometimes even hang on reboot. Not good, especially as it happened a few times while I wasn't home. I guess I should have heeded the warning about the zfs integration being experimental...Things got worse when I added a wireless card and retired my access point. Roughly around this point in time I got fed up with this enough to go back and start building an OpenSolaris VM to try out a mail server setup similar to the one I'm running on FreeBSD.

Before I got anywhere with this, FreeBSD 8.0 came out, so I upgraded. Zfs had be promoted from experimental, the wireless stack has been overhauled, etc pp. The stability problems disappeared and the machine has been utterly reliable since then. Where before, trying to use Time Machine from to back up my MacBook via the wireless network was a good way to a 50% chance to crash the server, it now "just works". This is where I wanted to get and I've now got there. Performance also seems to have improved - copying large files from the server to my Windows 7 machine sees a reliable 78MB/s via my Gigabit network now.

I've still got a couple of small changes I want to make to the machine - for example, I've got 4GB of RAM that I want to put into the machine. This should enable zfs readahead which should give me further performance improvements. I also plan to add two more fans to blow cold air over the hard drives to keep them happy and working for longer.

If I built another machine, I would probably get another motherboard. Not that there is anything particularly wrong with the one in the machine, but the CPU fan speed control only goes down to 70%, so no wonder that the CPU fan is noisier than it should be.

Was it worth it? Overall I'd say yes, although I probably should have stuck to tried and tested technology (either using FreeBSD's built-in RAID5 or use OpenSolaris with zfs). This caused unnecessary problems at the beginning and pushed up the cost as I was dithering between either. Next time I probably set up the server on OpenSolaris and run the mail server on FreeBSD in a VM running on OpenSolaris. Given that the current configuration is working, I leave it alone for the time being though.

A bunch of potentially useful links

nospam@example.com (Timo Geusch) — 2009-12-20T15:49:00Z

I'm preparing for an intercontinental move over the next few months so my apologies but there will be even less posting going on here than usual. Nevertheless I haven't forgotten the blog and things will return to normal eventually.

So for temporary entertainment and my own "don't forget these links" extended storage solution, here are a bunch of interesting Emacs and C++ links I came across in the past few weeks:

Interesting presentation showing various compilers' ability to optimise code.

emacs-fu blog post on making Emacs buffer names unique using Uniquify. I like this much better than the regular <number> scheme.

Interesting article on C++ by Peter Seibel. His new book is definitely on my Amazon wishlist; I've got Practical Common Lisp and rate it highly, plus I've heard a lot of good things about this particular book.

Very cool article by Walter Bright about porting OptLink from Assembler to C. I've used Optlink in the past when I used Zortech C/C++ and Symantec C++ and it was impressively fast. It's good to see that Walter is trying to preserve the technology employed in it. Plus of course I'm a sucker for slightly weird projects.

The little exception shop of horrors

nospam@example.com (Timo Geusch) — 2009-10-11T08:40:00Z

Exceptions - as we probably all agree - are generally a good thing as they allow us to separate the error handling from the general flow of control inside a program and also enable us to handle errors at the most appropriate point, which might be quite far removed from the source of the exception.

Imagine my surprise when I came across the following gem that was almost worthy of the Daily WTF:

catch (std::string ex) {
  // Do something horrible with the exception
}
 catch (const char *ex) {
   // Eh?
 }
 catch (int i) {
   // Uh oh
 }

I guess in some circles, being able to throw any sort of POD or object as an exception is considered a good thing. It's not necessarily considered to be a good thing when I'm around...

For the moment we'll also gloss over the advisability of catching exceptions by value. That doesn't mean I'm condoning that sort of coding.

But wait, it gets better. You thought that the code snippet above was part of a larger chunk of code that I omitted, didn't you? Well, it actually wasn't - it was all parked in a header file.

In order to avoid duplication of code - always a worthy goal - the above header file include wherever needed, so at least one of the files was full of code like this:

void doSomething() {
  try {
    // Lots of processing that might throw
  }
#include "catch_clauses.H"
}

Pass the Stroustrup, I need to refactor a developer or three...

A couple of useful Emacs modes

nospam@example.com (Timo Geusch) — 2009-10-06T17:40:29Z

highlight-changes-mode – as the name implies, it highlights changes that you make to a file. I do find it useful for the typical scenario of checking out a file, making a couple of smaller changes to it and then having to diff it to work out what you actually changed. As mentioned over at Emacswiki it doesn’t play too nicely with font-locking but I’ll try out some of the suggestions in the “Taming Highlight-Changes-Mode” section on this page.

nxml-mode – my preferred mode for editing XML. Of course it would be better if I could be bothered to create schemas for some of the files I’m editing but even without them, it does a pretty good job. As it’s trying to parse the XML that you write, it’s very helpful when it comes to highlighting mismatched tags or auto complete tags.

ido-mode – I’ve only recently started to use it and I’m still trying to work out if it is useful enough for me or if the improved file finding capability does bother me more than it helps. Yes, I know it can do a lot more but so far I’m only using the improved file finding and buffer switching. I really rate the buffer switching which is the main reason I leave it turned on.

Not really a mode, but I like using bm.el for visible bookmarks. I don’t use bookmarks that often but the package is extremely useful when I do need them.

A vote for the specialised Generalist

nospam@example.com (Timo Geusch) — 2009-10-01T07:12:44Z

There is an expression in German – calling someone a Fachidiot. I don’t think it translates very well into English as there isn’t an expression that conveys the same notion. Idiot savant is getting close, though. What the German word describes is a person who knows everything about very little.

While the opposite – knowing a little about everything - isn’t really desirable either, the Fachidiot type programmer seems to be highly prized by employers. From a business perspective this is understandable. The programmer who already knows everything about a very small field[1] can really hit the ground running, to quote one of my least favourite recruiter-speak. Not only can the hit the ground running, they’re very likely to run into the right direction. Obviously this is a good thing because it saves on training expenses. Given that there are plenty of employers out there who seem to view training as something they grudgingly have to pay for to stop their programmers from legging it at the first opportunity. But I digress.

However, from a career perspective, is being the Fachidiot type programmer really desirable? I doubt it, for several reasons.

Continue reading "A vote for the specialised Generalist"

Using pantheios to log inside a C++ JNI DLL

nospam@example.com (Timo Geusch) — 2009-09-24T19:44:00Z

I recently had to come up with a logging solution for a JNI DLL/shared library that was written in C++ and is providing the data translation layer between Java and the native libraries. As usual, some logging was required to aid fault finding in a production environment, if necessary. A quick survey of the state of C++ logging showed that not a lot had changed since I last looked at logging libraries for C++. In fact, a lot of them seem to have survived unchanged for several years. I'm not sure if that is a good thing and a sign of maturity or a sign of "making do". Eventually I settled on pantheios as it offered a bunch of features that were crucial for this application. The major one was that it is extremely modular and will only link in the parts you really need. I consider this a major advantage over the more monolithic libraries that pull in all their functionality all the time, especially when you link them in as a static library (yes, log4cxx, I'm looking at you). Linking in the logging library as a static library was a necessity to avoid conflicts with other libraries that are being used in the same process.

Continue reading "Using pantheios to log inside a C++ JNI DLL"

Some clarifications regarding last week's anti-VC6 rant

nospam@example.com (Timo Geusch) — 2009-09-09T21:02:28Z

This post started out as a comment to Len Holgate's post referencing my anti-VC6 rant. The comment got a little out of hand size wise so I've decided to turn it into a separate blog post. I think I mixed a couple of issues together that should been separated better but weren't - after all, my blog post was more of a rant.

First, if your client or employer is maintaining an existing system and the system is in maintenance mode only, we're talking about a bug fix or a small enhancement then it doesn't make sense to upgrade the compiler. That's what I was referring to as a system that is "on life support". Yes, it goes against the grain for me personally as a software engineer who likes to improve software but the effort spent on making the transition does not make sense from a business perspective.

What I do take issue with is when you are developing a new system or are working on a large refactor of an existing system that is in "embrace and extend mode", and for whatever reason the client or employer decrees that it shall be written using VC6. That's where the penalties come in and that is where the technical debt builds up at the start of a new project or at the exact point in time when you should be addressing the debt instead of adding to it.

The understanding of C++ and the use of its multi-paradigm nature has changed since VC6 was released, we have both new programming techniques and new libraries that (should) improve the quality of the code, its expressiveness and programmer productivity. The prime example of these libraries and the one I was thinking of when writing the rant of course is Boost. The earliest MS compiler they test against in 1.40 is VC7.1 aka VS2003 which is certainly a big improvement over VC6.

Yes, VC6 is likely to create smaller executables and build them faster. C++ compilers certainly are not getting any faster and long compile/link times have been a problem on projects I worked on. Shorter build times and especially smaller executables can be a benefit depending on your particular use case. A lot of the projects I worked on in the recent past are maths heavy and the calculations are performance critical. For these projects, an compiler that has an optimizer which can squeeze a 5% performance improvement out of the existing code one a modern CPU at the expense of 20% larger code is a no brainer. In at least one case it was cheaper to buy the Intel compiler to get better performance instead of putting more engineering time into performance improvements.

Yes, developers like shiny new tools and yes, I've worked with developers who considered GCC's CVS HEAD the only compiler that was recent enough to complement their awesomeness. This is not something I generally agree with although I did update my own copy of Visual Studio from 2003 to 2008 (yes, I did skip 2005) when that version came out simply because it was so much better than its predecessors.

I still think that by insisting on the usage of tools that are positively ancient, programmers get needlessly hobbled and it is part of our job as programmers who care about what they do to educate the people who make these decisions as to why they aren't necessarily good from an engineering point of view. I don't think any of the Java programmers I work with would put up with having to work using Java 1.2 and forego the improvements both in the language and in the available libraries, yet C++ programmers are regularly asked to do exactly that.

Why oh why do people insist on using compilers that are way out of date?

nospam@example.com (Timo Geusch) — 2009-09-02T20:31:00Z

Why are so many companies hobbling their programmers with positively ancient and often positively crappy tools? For once I'm not ranting about companies that are too cheap to provide their C++ programmers with important tools like profilers and leak detectors - the usual "if these were important, the tool vendor would include them" argument, but the one tool right at the heart of the matter. The one none of us can work without in C++ space. I am, of course, talking about the compiler.

One of my personal pet hates is the number of projects that are still using Visual C++ 6 - for $DEITY's sake, that compiler was released back in 1998 and it wasn't that good back then. Microsoft has since released four new versions of their C++ compiler and a fifth is due very soon. Each one of them is better and more importantly, more standard compliant than its predecessor. All have benefited enormously from people trying to push the boundaries of what you can do with C++ in the past eleven years. Oh, and mainstream support for the compiler ended years ago, but who's counting? Yet companies still insist on using this outdated piece of <censored>, depriving their programmers of the ability to use more modern C++ techniques that often make for a safer programming environment.

If your code doesn't build with a modern, standard compliant compiler and you're not about to switch off the life support for your project (just about the only justification IMHO for working with ancient tools), the go ahead and get it to compile on the newer version of the compiler. Postponing the conversion will only add to your technical debt until that gets to the point where you, well, switch off life support...

A couple of interesting blog posts...

nospam@example.com (Timo Geusch) — 2009-08-23T08:16:00Z

A couple of links to other people's interesting posts I've come across in the last few days.

Raymond Chen on "There is no law that says meetings can't end early". I wish more people would take this advice to heart, but that's been on my Christmas wishlist right next to "create an agenda for a meeting and stick to it".

Interesting blog post regarding the difference between technology for technology's sake and using technology to create something. For the record, I tend to be more interested in doing something with my technology "toys" rather than having them purely for having them. That's probably one of the reasons that I tend not to have the latest, greatest and fastest machines (or phones, cameras etc) but rather buy quality kit and use it for a few years instead.

Do programmers still buy printed books? I know I do, but I'm getting a little more choosy. I've bought a couple of books recently that I'd classify more as a waste of a perfectly good tree. That's unfortunately not unusual for tech books, there are a couple of brilliant ones out there and an awful lot of, how shall I call it, rubbish. I'm also one of those throwbacks to an earlier age who prefer to hold a physical book in their hands rather than stare at a screen. The reason Antonio mentions - switching between book reading mode and computing mode - certainly has something to do with it; after all, if you're immersed in a book you probably don't check your email every thirty seconds whereas I'd be tempted to do that if I were to read the book on a computer. Reading on the iPhone is something I'd rather not do, my eyesight is bad enough as it is...

Antonio's book list his previous blog post also looks very much like I should update my Amazon wish list.

Uncle Timo's carrer corner: Today's top interview tip

nospam@example.com (Timo Geusch) — 2009-08-20T06:19:07Z

If you're conducting an interview using your mobile phone (that's a cell phone to the readers on the other side of the pond), at least go somewhere with good reception so the interviewer can hear what you're saying. If you don't you're probably not going to make a very good impression if the interviewer has a hard time understanding half of what you say...

My emacs configuration file refactor

nospam@example.com (Timo Geusch) — 2009-08-18T12:27:35Z

In a previous post I described that a few months ago, I moved the third party elisp code under version control to make it easier to move it between machines and ensure a consistent configuration across them. The one remaining problem to solve was putting the configuration files (.emacs and .gnus.el) under version control. One of the approaches I really liked was described by Nathaniel Flath but I figured that it was too heavyweight for my needs.

What I ended up doing was to move the configuration files into version control and then simply change the basic dot-files to load the file from the subdirectory that is under version control. My .emacs now reads like this:


(load-file "~/emacs-lisp/dot-emacs.el")

Not the most elegant and automated version but it works for me.

Building a new home NAS/home server, part IV

nospam@example.com (Timo Geusch) — 2009-07-30T19:51:00Z

I've done some more performance testing and while I'm not 100% happy with the results, I decided to keep using FreeBSD with zfs on the server for the time being. Pretty much all measurements on Linux (both a recent Ubuntu Server and CentOS 5.3) showed lower performance and while OpenSolaris is a lot faster when it comes to Disk I/O and thus would have been my first choice for a pure NAS, the effort in porting my current mail server configuration would have resulted in the server being ready sometime in 2010...

I might be exaggerating this a little but the effort of building amavisd-new is non-trivial due to its large number of dependencies. If packages or at least some sort of package build system like the FreeBSD ports is available but building it from scratch and ensuring that all the necessary small Perl components are present isn't trivial. So FreeBSD it is for the time being. I will still be looking into rolling a few packages for OpenSolaris for at least some of the tools I'd like to see on there as the thought of running my home server on what is essentially an enterprise-class OS is very appealing to me.

Continue reading "Building a new home NAS/home server, part IV"