[Serialization] Things that should be qualified.
Aside from boost/pfto.hpp, there are several other examples of Boost.Serialization-specific functionality that was inappropriately pushed up into the top-level namespace. These headers are all in that category: boost/smart_cast.hpp, boost/state_saver.hpp, boost/static_warning.hpp, boost/strong_typedef.hpp. There is also at least one macro in that category: BOOST_EXPORT. That in particular seems likely to cause problems, because after all "export" is a keyword that's supported only on a few compilers and a natural stand-in, for those who want to support export, would be BOOST_EXPORT. This should've been BOOST_SERIALIZATION_EXPORT. This is clearly a broad issue across the serialization library design, and I request that Robert examine these and any other instances of the problem and take whatever steps are practical to correct it. Because some of these names are in the library's public interface, that may require a plan that spans several Boost releases. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Aside from boost/pfto.hpp, there are several other examples of Boost.Serialization-specific functionality that was inappropriately pushed up into the top-level namespace. These headers are all in that category: boost/smart_cast.hpp, boost/state_saver.hpp, boost/static_warning.hpp, boost/strong_typedef.hpp.
There is also at least one macro in that category: BOOST_EXPORT. That in particular seems likely to cause problems, because after all "export" is a keyword that's supported only on a few compilers and a natural stand-in, for those who want to support export, would be BOOST_EXPORT. This should've been BOOST_SERIALIZATION_EXPORT.
BOOST_DLLEXPORT, BOOST_USED, ...
This is clearly a broad issue across the serialization library design, and I request that Robert examine these and any other instances of the problem and take whatever steps are practical to correct it. Because some of these names are in the library's public interface, that may require a plan that spans several Boost releases.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
David Abrahams <dave@boost-consulting.com> writes:
There is also at least one macro in that category: BOOST_EXPORT. That in particular seems likely to cause problems, because after all "export" is a keyword that's supported only on a few compilers and a natural stand-in, for those who want to support export, would be BOOST_EXPORT. This should've been BOOST_SERIALIZATION_EXPORT.
BOOST_DLLEXPORT, BOOST_USED, ...
If that macro does what I think it does BOOST_DLLEXPORT is a bad choice. DLL exporting macros *must* be library specific otherwise boost libraries can not use each other. For an example look at the AFX_DLL mess MS created. Thomas -- Thomas Witt witt@acm.org
Thomas Witt <witt@acm.org> writes:
David Abrahams wrote:
David Abrahams <dave@boost-consulting.com> writes:
There is also at least one macro in that category: BOOST_EXPORT. That in particular seems likely to cause problems, because after all "export" is a keyword that's supported only on a few compilers and a natural stand-in, for those who want to support export, would be BOOST_EXPORT. This should've been BOOST_SERIALIZATION_EXPORT.
BOOST_DLLEXPORT, BOOST_USED, ...
If that macro does what I think it does BOOST_DLLEXPORT is a bad choice. DLL exporting macros *must* be library specific otherwise boost libraries can not use each other. For an example look at the AFX_DLL mess MS created.
Yes, I know. I didn't even want to touch *that* issue until the larger issue of namespacing/prefixing was addressed. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
David Abrahams -
Thomas Witt