XTide 2 is written in portable C++. I have avoided using any of the fancier, less portable features of C++ such as the "standard" C++ class library, exceptions, templates, and namespaces. The only thing I am really using is the core C++ language, i.e., classes and overloading. If there is any problem compiling XTide with any C++ compiler, ANSI-compliant or otherwise, I will attempt to address it. (Someday this C++ portability stuff will all seem quaint.)
XTide 2 conforms to the honorable old tradition of having command line switches be no more than two characters long, except where needed for compatibility with X11.
The usage of XML for subordinate stations is because I have gotten burned again and again by the inflexible format of the harmonics files. The expensive extraction of coordinates from comments is a result of this legacy. However, the cost of using XML is that it's harder to cut corners in the fast loader. It could be done, but currently I'm just gambling that Moore's Law will outpace the growth of offsets.xml.
The Right Solution[TM] is to quit doing database type things in XTide and instead put all of the harmonics data into a Real Database[TM]. I'll be first on the bandwagon whenever Postgres becomes a required feature of every Unix installation.
Known design problems:
The good news, anyway, is that the NOS system of tide prediction that XTide implements is not totally obsolete yet. Tide agencies around the world are moving to secretive systems with hundreds of constituents, jealously guarding the data from public use, but the U.S. is still using the same old system, and it still works great. Regardless, XTide 2 should expand to handle Doodson data and whatever else becomes necessary. With the XML parser, it's no big deal to add totally new kinds of tide stations that will be handled by newer XTide versions and ignored by older ones.