There is another warning which is missing from the documentation: portable code can not rely on BOOST_CLASS_EXPORT to register a class unless the user explicitly calls a function from a compilation unit that "sees" that particular BOOST_CLASS_EXPORT call. This is because it relies on a global object's constructor to initiate the registration process, but a good compiler will deadstrip all such global objects unless the user explicitly calls a function from the compilation unit that defines them. In other words BOOST_CLASS_EXPORT isn't automatic because a portable program is required to (manually) call a (possibly empty) function from the registered class' cpp file. This is contradictory to BOOST_CLASS_EXPORT's intended use to register derived classes automatically, just by linking their cpp files.
I don't think that's currently true - if it ever was. The code specifically addresses this issue with a number of compiler specific adjustments to insure that code is not stripped. These adjustments have proved effective for all compilers/linkers that boost supports (with the possible exception of CodeWarror). So maybe its true were the system compiled on a strickly comformant compiler which has no extensions to prevent code stripping, but as far as I know, there is no such compiler being used. I also believe that its unlikely that any such compiler/combination will ever see the light of day since it would be useless for building DLLs (shared libraries).
The key word in my statement is portable. I know there are non-portable workarounds on most compilers, but next versions of these same compilers could require a new workaround, and the standard tells you that such workaround may not be possible. Preventing a global object from being deadstripped still does not guarantee that it will be initialized before you call a function from its compilation unit. Suppose you have a global object that allocates a lot of memory, this provision in the standard allows the compiler to postpone this allocation until it is actually needed. In several large code bases I have spent many hours fighting with this same issue of various registration schemes being deadstripped because they rely on a global object to boot. In fact what prompted my post is that I'm currently having the same problem with a popular 3D engine. I have to dig through all of their macro trickery, static class members and whatnot, to figure out what needs to be initialized -- It's very frustrating, and by far outweights any benefits of their "automatic" registration. I think that no harm would be done if the documentation states that BOOST_CLASS_EXPORT relies on compiler-specific tricks and is not portable. This is especially important for a Boost library. Emil Dotchevski