The lone C++ coder's blog - C++ programming

A neater way of handling common exceptions

nospam@example.com (Timo Geusch) — Thu, 04 Feb 2010 21:38:00 +0000

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"

The little exception shop of horrors

nospam@example.com (Timo Geusch) — Sun, 11 Oct 2009 09:40:00 +0100

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...

Using pantheios to log inside a C++ JNI DLL

nospam@example.com (Timo Geusch) — Thu, 24 Sep 2009 20:44:00 +0100

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) — Wed, 09 Sep 2009 22:02:28 +0100

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) — Wed, 02 Sep 2009 21:31:00 +0100

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...

Using polymorphism with boost::shared_ptr

nospam@example.com (Timo Geusch) — Mon, 25 May 2009 10:17:29 +0100

I'm currently in the final stages of converting a library from using raw pointers to using boost::shared_ptr. This is mainly done to resolve issues with pointer ownership rather than the outright prevention of memory leaks, but the latter is a nice side effect of the former.

The one problem that I ran into during this work was that the library and its clients make rather heavy use of polymorphism. Of course in 99% of the code that was fine as the objects were accessed through pointers to base classes, but the last 1% was causing problems because that part of the code contained lots of dynamic_cast statements. As these classes unfortunately needed to know the exact type they were dealing with, there was no easy way around the use of these idioms, either. It probably isn't news to most of the people reading this blog that dynamic_cast and boost::shared_ptr don't play that nicely but I stepped right into that.

The main issue is, unsurprisingly, that taking a pointer that is held inside a boost::shared_ptr, dynamic_casting it down the hierarchy and then stuffing it into another boost::shared_ptr is a good way to ensure double deletion. Oops. So, if you see the following code you better get the debugger out...



   boost::shared_ptr<A> something(new A(blah));
   ...
   boost::shared_ptr<B> something_else(dynamic_cast<B>(something.get()));

So far so bad, but I couldn't believe that something with a flaw that obvious would be in the boost libraries. And of course, there is a way around this - boost provides alternatives to the four C++ casts with similar names that work on boost::shared_ptrs. You can find these alternatives - which are really just wrappers around the C++ casts, but designed to work with the boost smart pointers - in the include file boost/pointer_cast.hpp.. If you're using smart pointers because you need polymorphic behaviour of, say, items stored in standard C++ containers, have a look at this page right now. If you don't have the time or inclination to check the linked document right now, the management summary is: "The next time someone tells you that you can't use boost:.shared_ptr with dynamic_cast, point them in the direction of boost::dynamic_pointer_cast". Using boost::dynamic_pointer_cast would change the above example to:



   boost::shared_ptr<A> something(new A(blah));
   ...
   boost::shared_ptr<B> something_else =
      boost::dynamic_pointer_cast<B>(something));

Problem solved.

Auto-parallelising compiler

nospam@example.com (Timo Geusch) — Wed, 25 Mar 2009 11:29:43 +0000

This looks like a big step in the right direction. As Herb Sutter repeatedly pointed out, writing correct parallel programs is a lot harder than writing a correct sequential program so a compiler that can take over part of the work is definitely a good thing.

Speeding up Visual C++ compilation by cleaning up the include paths

nospam@example.com (Timo Geusch) — Tue, 23 Dec 2008 15:46:05 +0000

As I had hinted at in a previous blog post, I have been working on a script that would substitute unqualified #include directives of the form
#include "SomeClass.H"
with #include directives that contain relative include paths of the form
#include "module_path/SomeClass.H"

Obviously I wasn't making these changes because of their inherent beauty and style; I had a very simple reason for this endeavour - the build times of the project I am currently working on are rather long. We're talking 1-2 hours on a decent desktop PC, which does not do much for turnaround times and does inhibit developer productivity somewhat as it's hard to stay in the zone while watching the compiler do its work. Slowly. One very large module in particular is taking up approximately half the build time in the default build so that was the obvious candidate for improvement.

Continue reading "Speeding up Visual C++ compilation by cleaning up the include paths"

Checking library versions during build time

nospam@example.com (Timo Geusch) — Sat, 11 Oct 2008 12:06:00 +0100

Management summary: If your product requires a specific version of an external or internal library, make sure your build breaks if you use a different version...

Another of these problems that only ever seem to see the light of day - or night, mostly - when you really, really need to get something finished and it's already 9pm. At that point you'll hit some strange behaviour that's hard to reproduce and oddly enough, only shows up on your machine. Trouble is, you need to either work around the bug or fix something nobody else can see.

At around 2am, when some of your colleagues a lot further East turn up for work and you finally have someone to talk through the problem again, they casually mention that everybody else on the project is using libgbrmpzyyxx version 1.23 whereas you, who joined the team later and was just told to "go download libgbrmpzyyxx" and thus ended up with version 1.31, which contains a few important bugfixes and unfortunately another bug that you just found. Congratulations...

Of course, everybody knew that the One True Version of libgbrmpzyyxx was 1.23 but you somehow didn't managed to acquire that pearl of wisdom via osmosis. Sounds familiar?

Fortunately, there are some strategies that you can employ to avoid this sort of late-night scenario.
Continue reading "Checking library versions during build time"

Non-intrusive C++ build speedup, part II

nospam@example.com (Timo Geusch) — Tue, 26 Feb 2008 22:18:37 +0000

After the success in substantially accelerating the project's build time in Visual C++, I tried the same method on the Linux build using gcc. Unfortunately using the same header file that I used with Visual Studio and the same 'force include' technique as suggested by Paolo Bonzini, it appears that the build is actually slower rather than faster. Digging through the GCC documentation so far hasn't yielded any explanations and I'm still a bit perplexed by the result. Same speed or faster I would have expected but slower?

Anyway, I'll keep digging a bit more tomorrow and hopefully will find out what the problem is...

Book recommendation - C++ Coding Standards

nospam@example.com (Timo Geusch) — Mon, 07 Jan 2008 21:41:49 +0000

I know, it's been out a while but as usual I'm a bit behind with my reading. Anyway, if you haven't read "C++ Coding Standards" by Herb Sutters and Andrei Alexandrescu, get someone to buy you a copy. Actually, if you can't find someone to buy it for you, go buy it yourself with your own money. Nonewithstanding the fact that the words "coding standard" are considered dirty words by most programmers, this book makes a lot of valid points and more importantly, it makes you think.

The format is similar to Herb Sutter's "Exceptional C++" books inasmuch as its topics are arranged in series of short, concise points so the format will feel familiar to a lot of people who are likely to buy the book.

Non-intrusive build speedup in Visual C++ .NET

nospam@example.com (Timo Geusch) — Wed, 19 Dec 2007 15:06:00 +0000

Recently I've attempted to reduce the build times of a client's project - said project takes about 90 minutes to build from scratch on a Windows box using Visual Studio .NET (2003). I do realise that one of the easier ways to shorten build times is to simply move to 2005 and make use of its parallel build feature. While that is on the cards, the actual speedup from a move to 2005 isn't as big as I hoped for. VS2005 does only build (sub)projects in parallel, and two subprojects do take a disproportionate amount of time to build.

This project is cross-platform and as such, I was looking for minimal invasive surgery on the build process to speed up the Windows build process without affecting any of the other platforms. A lot of the Old School ways of improving build times had already been applied - for example, the include guards are checked in the including files to prevent double inclusions (as John Lakos recommended in his book "Large Scale C++ Programming"), almost all headers have include guards and so on.

My first thought - which was anything but minimally invasive - was to add a suitably protected '#pragma once' to all includes. When I did measure the resulting build times I was a bit surprised - on my desktop machine, there was no difference in build time outside the measuring tolerance. On the laptop that I work on when working remotely, there was a measureable acceleration, but we're still talking in the order of 5%, up to about 8%-9% on a really good run. It seems that VS 2003 is already doing a pretty good job of caching headers, so the difference that #pragma once make seem to show mainly on machines with relatively little RAM and slow harddisks. At this point I went onto another Google spree and found that this article on Games From Within had arrived at the same conclusions. Which left only one obvious way of improving build times and that was by using precompiled headers for the Windows build. And the Windows build only...

The obvious way to use precompiled headers would have been to create a script that iterates over all .cpp files in the project, checks them out from version control and adds the line including the precompileable header. Such a script is not exactly hard to write - depending on the version control system you're using, you may not even have to check out the files before being able to change them. Nevertheless, this approach very much violated the 'minimally invasive' requirement. In other words, I didn't want to change the source code at all.

Continue reading "Non-intrusive build speedup in Visual C++ .NET"

A new secret c++ weapon in my arsenal

nospam@example.com (Timo Geusch) — Fri, 19 Oct 2007 06:51:32 +0100

A couple of days ago I finally got around to buying a copy of Gimpel's PC-Lint tool. Obviously this is a tool that 99% of the world's C++ programmers don't need as they already writing the most perfect code possible, but for those of us who have learned the hard way that they are mere mortals and not masters of their universes, it is a very worthwhile tool. So far I haven't done much with it; I just ran it over a couple of files that I was refactoring anyway. Nevertheless I picked up a couple of valid hints about further improvements to the code. As always with lint tools, you need to spent some time tweaking the configuration until it's "just right" for your project as it'll drown you in hints and warnings otherwise. Some of these warnings may be utterly irrelevant to your project or outside your control - in my case, I got a ton of warnings from some third-party library header files that I can't do anything about anyway. After the configuration, the next step on the agenda is to integrate it with (X)Emacs on Windows so I can lint files directly inside the editor. Guess I'll have a Google first to see if anybody's written any code for that yet or if I have to go and ~~bodge~~build something that abuses compile-mode or similar to accomplish this goal. Good thing I've recently bought Peter Seibel's Practical Common Lisp to refresh my very rusty Lisp skills.

Visual C++ 2005 time_t changes

nospam@example.com (Timo Geusch) — Tue, 07 Aug 2007 06:55:00 +0100

Over the past couple of days I've tried to get a client's application to build (and then hopefully to work...) on Visual Studio 2005. Most of the problems highlighted by the conversion were fairly trivial and a result of the better standard compliance of the compiler, but the change in the size of time_t caught me out initially.

Continue reading "Visual C++ 2005 time_t changes"

A more up-to-date comparison of C++ unit testing frameworks

nospam@example.com (Timo Geusch) — Thu, 24 May 2007 07:58:31 +0100

While there are a lot of C++ unit testing frameworks out there - sometimes you get the impression that there are nearly as many as there are logging libraries and string classes - there don't seem to be that many well-researched comparisons of those frameworks.

That said, Chris Main published an article in Overload comparing a few more modern frameworks. Worth reading in my opinion, even if it's just to keep up with what's going on.