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
