Robert, Thanks for the pointer. I finally got it working--after a couple of false starts, whic bring me to the subject of this message. :-) I don't know if you've noticed, but those deceptively simple macros can cause problems in applications that use their own namespace. For example, BOOST_IS_ABSTRACT() expands into two nested namespace declarations enclosing the code that gets expanded. So, if this macro is placed inside of the application's declared namespace block, then the application's namespace gets prepended to the boost namespace, making the code fail. If you then move BOOST_IS_ABSTRACT() out of the application's namespace block, the expanded code works, but now it claims it never heard of , since its no longer automatically picking up the application's namespace. The documentation for BOOST_IS_ABSTRACT() needs to be changed to warn that it must be used ONLY at the global, default namespace level and that the needs to include any application namespace. On the other hand... The BOOST_SERIALIZATION_BASE_OBJECT_NVP(<name>) macro expands into a single function call with the boost namespaces prepended to the function name. This means that this macro can be used anywhere regardless of any enclosing application namespace block--but now the class name has the wrong namespace. Even if the macro were used inside the application's namespace block, the class name argument is quietly put in the boost namespace, where it isn't known. So, again, the class name must have the application's namespace explicitly prepended--even though it's inside the application's namespace block. It would be nice if these macro all behaved the same in the presence of an application namespace. And, you should warn to always explictly state the applicaiton namespace, if any, on class name arguments--but not method names. Merrill