Boost for C++ developers has lost its shine

I have decided that I don't like the C++ boost libraries with just two minor exceptions. The exceptions are the smart pointers that are part of TR1 and boost threads (along with their mutexes and condition variables). They're ok. I haven\'t used all of the rest but I have used the following: --filesystem --named semaphores and named mutexes --sockets (asio) --POSIX date/time I have also looked briefly at the graph library but not actually used it. In the above cases my criticisms are the same:

• I have found several cases where the code does not work. Examples include:
  • filesystem: has difficulty with UNCs
  • named semaphores/mutexes: does not cleanup properly and does not use the underlying WIN32 primitives on MS-Windows.
  • sockets: Counterintuitive model that is contrary to the way that BSD sockets work. For example, async_accept does not do an asynchronous accept!

• The source code is template mania. It is VERY hard to understand. Compare this with Poco or ACE where the code does what you would expect, more-or-less how you would expect.

• The code does not have a clean separation for those parts of the implementation that are platform-dependant. This is very hard to do well but Poco manages to pull it off nicely. Boost fails dismally.

The more I look at boost, the less I like it. It seems to me that it is a prime example of what happens when you give a problem to academics to solve. You get a convoluted solution that only appeals to the Elite and is not very practical. In future, I hope that I get the chance to use Poco for my foundation C++ classes.

NTFS junctions are a poor substitute for symbolic links

Recently, I have been working in a Windoze-XP environment using multiple sandboxes checked out from CVS. Each sandbox needs a large collection of third party libraries (headers, lib and .dll files). Each third party directory takes up around 2GB. This space very quickly mounts up. In Unix we would use symbolic links to make all the third party directories point to a common place. But what to do in Windoze? Some people would say that NTFS junctions is the answer. Well, they can help and I am using them for this purpose but there are some nasties and I am documenting them here. I once saw a signature on USENET which goes: "Those who do not understand Unix are condemned to reinvent it, poorly." This is certainly true of Windoze. It doesn't understand symbolic links so it is no suprise to learn that NTFS junctions are a very poor imitation. Here are several points to bear in mind:

• They are a cross between hard links and symbolic links. Like the hard link, they can onloy refer to files on the same partition, but like symbolic links the path of the link is stored which means it can become invalid. This is because Windoze filesystems do not support links! Also, only directories can be linked.
• Windoze-XP has insufficient support for NTFS junctions despite them first appearing in Windoze-2000. There are no commands to manipulate them. You will have to download and install the SysInternals commands and use the junction command.
• More explicit support for NTFS junctions was added to Vista and is also in Windows 7. But even by these versions of Windoze, support is incomplete. When you use Windows Explorer to navigate to a directory that contains NTFS junctions, if you delete the directory it deletes the files that the junctions refer to!!! See http://shell-shocked.org/article.php?id=284 for the gory details.

The only way to delete a junction safely is to the use the SysInternals junction command. There is no safe way to delete a directory that may contain junctions. Currently, I do not know what the solution is to these problems. The cygwin rm command does not help, it follows the junction references just like Windoze Explorer does. I have a feeling a special delete command may have to be written. I will probably have to write it, in Python, and it will probably use the SysInternals junction command to delete any NTFS junctions it finds.

cron on Windoze using cygwin

There is quite a useful little document, http://csc.csudh.edu/kleyba/cygwin-cron.pdf, that explains how to install the cygwin cron, complete the cygwin setup screenshots. Very nice. But there is a little nasty when setting up cron in a corporate network. Typically the home directory is a network drive which will not be accessible. It took me a while to work out what was wrong and how to fix it. Some of the advice I found whilst googling turned out to be wrong. I tried setting HOME in the crontab. No effect. I tried seting HOME as an environment variable in the control panel. No effect. Finally I edited /etc/passwd and changed the value of the home directory field from /cygdrive/u to /cygdrive/c. Problem solved! Also, note that the pdf document says how to run the cron config command. This was very helpful because other web pages omit this and it turns out to be crucial to getting the service running. Without that config the service gets installed but dies as soon as it starts up.

Setting up PHP and Apache on Windoze

This link is very useful: http://www.thesitewizard.com/php/install-php-5-apache-windows.shtml I mention it here instead of adding it to my list of bookmarks. After all, it's not going to be done every day, is it?

IBM MQSeries queue viewer (Hermes)

At long last I managed to get JMS Hermes working with IBM MQSeries queues. These notes are about how I did it. First, there is a very useful install guide at

http://www.hermesjms.com/confluence/display/HJMS/Installing

A little detail it misses out is that you must set JAVA_HOME as well as HERMES_ROOT. Also, when you track down the jars for MQ, you might find it hard to find the PCF jar. I found it at

 http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg24000668&loc=en_US&cs=utf-8〈=en

Finally, there is a flash tutorial at http://www.hermesjms.com/demos/demo_mq.html. It is a little out of date but still very helpful.