Bloggy

Check out this GCC Symbol visibility patch. It can have quite an effect on code, especially code (*coughC++cough*) that generates very large symbol tables.

Posted by mpyne under Uncategorized | No Comments »

I had a discussion on #kde-devel today with a developer who didn’t know about how to build programs with a different build and source directory. It came as quite a shock to me, as I had assumed that it was common knowledge.

It never hurts to spread the word, though, so here’s how it works:

1. You need to have already unpacked the source, let’s call that directory srcdir.
2. If you need to run make -f Makefile.cvs, run that in $srcdir, not $builddir.
3. You need to make sure your build directory has been created, and change directory to the build directory.
4. While in the build directory, run the configure script from the $srcdir. It will perform the configure process like normal, with the exception that all of the Makefiles and other generated files end up in $builddir, not $srcdir.
5. Go ahead and use make like normal.

That’s nice, you’re thinking, but why would you want to use builddir != srcdir you ask. The answer is because it makes it easier to do a clean rebuild, so that you can be sure a package that builds for you also builds for someone else, or maybe you’ve b0rked a Makefile beyond repair. If you use KDE CVS, you can run make cvs-clean to get an equivalent effect, but that wastes bandwidth and server time, and doesn’t work when the network or server is down. Also, I’m not sure whether or not make cvs-clean will wipe out any changes you’ve made to the source code.

There are other ways of performing the same idea. XFree86 and X.Org include a tool called lndir (manpage), which is probably installed on your system, that creates a mirror image of a source directory by using symlinks. This has the advantage of ensuring the updates to the source are reflected in the symlinked files, but I have no clue how well it works or not, as I have not used it myself.

Posted by mpyne under Uncategorized | No Comments »

I come across this every so often and still get surprised by it every time. So I figured I’d impart a bit of my hard-earned C++ knowledge so that more people would be familiar with the phenomenon.

Basically, in C++, you need to be sure that base classes don’t require anything from subclasses in their destructor activities. It sounds obvious, but it can pop up in surprising ways.

Say you have a subclass of KListView (we’ll just call it FooListView), and a corresponding subclass of KListViewItem, FooListViewItem. Also assume that you’ve not been praying to the OO gods, and the FooListViewItem is a friend of the FooListView, and accesses the FooListView in its constructor and destructor (like for debugging, or so the FooListView can easily hold data on its FooListViewItems no matter how they were created).

Normally this would work well enough, but during shutdown, as the FooListView is being destructed, it gets destructed starting at the subclasses, and working towards the base. In this case, the destructor would run in this order: ~FooListView() -> ~KListView() -> ~QListView() -> etc. Now, if the FooListView doesn’t delete its little FooListViewItems, what happens? They will still be present when the QListView destructor run, and QListView will happily delete them for you.

But wait! Remember how the FooListViewItems accessed their parent FooListView? The FooListView is now gone, only the QListView methods are valid. So you will get a crash on shutdown if you are not very careful, and remember to delete all FooListViewItems from within the FooListView destructor.

There are other ways that having Qt handle memory management for you can bite you, but they usually are typically due to “poor programming practices”. However, we all have to perform a few hacks in any program of more than minimal complexity, so it is something to keep in mind the next time you have two classes that are innately related to each other.

Posted by mpyne under Uncategorized | No Comments »