Alo Sarv
lead developer

Donate via

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary

Monday, December 05, 2005

Further improving MSVC compatibility

Programmer (n): An organism that can turn caffeine into code.
- Unknown source

Another 15 hour dev-session, mainly focused still on improving MSVC compatibility. Support for MSVC 2005 Express Edition is now complete, altough the debug version of it's runtime library does rather aggressive checking, so assertion failures (inherent from Boost code) in debug builds still happen. One of the biggest surprises was code like this:
std::string tmp;
logMsg(boost::format("%s") % tmp);
This caused assertion, since Boost.Format library called std::string.append(0, 0), which, while technically valid operation (doesn't do anything), caused assertion by C++ runtime library. Boost people are aware of this, and hopefully a fix will be available at some point, but currently we have two options - patching boost headers, or disabling those checks completely. That doesn't seem to be an isolated incident either, additional assertion failures happened in different places, but I was unable to track those further yet.

Yesterday I also mentioned the problems with manifest files that MSVC 2005 introduced. What I found out is that this is part of Microsoft Fusion technology, something that will resolve the DLL hell problems once and for all (at least we'd like to think that). In any case, as I discovered, Boost.Build v2 (which we'r using) actually supports it, but it used it only for DLL's. However, as it turned out, it's required to merge a manifest into executables as well in the final versions of the compiler, so the build system was patched to do that.

Http module had some really strange problems when compiled with MSVC 8.0. Namely, it complained, during linking, about duplicate definition of Range::begin(), Range::end(), and Range::length() methods. Now, Range is a template class, with all-inline methods, defined in hnbase library, which made the issue even more odd. We spent practically two nights with wubbla scratching our heads at it, until tonight I managed to ask the right question in google, and stumbled upon this page. As it turns out, it's a rare linker bug (present since 2002 already), that triggers sometimes when a dll imports a class that's derived from a template class - in this case, it was probably LockedRange/UsedRange objects, which are derived from Range64. This was fixed by somewhat surprising code - explicitly import the template class, e.g.:
template class IMPORT Range;
I also installed and tested Hydranode using Intel C++ Compiler for Linux, which is free for open source developers. It detected two or three minor issues, mostly related to pointless comparisons of unsigned integers against zero (one of the checks could'v potentially caused problems). However, from the looks of it, intel linux compiler is more than twice slower in release build than GCC, so we won't be using that in long-term. Still, nice to know Hydranode now compiles cleanly with three different compilers (also shows that the Boost.Build system is indeed portable - there's almost zero compiler-specific things in the Jamfiles).

Enig123 discovered a rather critical issue with credits database handling in Hydranode. Namely, we never updated the lastSeen value of credits, which means eMule dropped ALL entries in our clients.met when it was loaded, since eMule cleans entries that are more than 5 months old. This was now fixed, the lastSeen value is set to current time if it's not set. Hydranode now also removes credits that are more than 5 months old (untested code - we'll see if it works in 5 months :)).

While debugging the assertion failures of MSVC 8.0, the first code that triggered them on startup was configuration file parser (due to a logTrace call in there); at the time I didn't know yet why it was causing it, so due to lack of better ideas, I rewrote the config.ini parser code to use Boost.Spirit parser engine, instead of the former hand-crafted string manipulation. This was actually something I had wanted to do for a long time, but never had time for it, so now it's finally done.

Madcat, ZzZz

Comments: Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?