
Daryle Walker <darylew@hotmail.com> writes:
[Top-post since the new stuff gives a fuller context.]
I think I need to explain things. (This is what I get for not reading Boost e-mail for a few days. I could have nipped this in the bud. I didn't find out about this problem myself until I tried a compile....)
1. <boost/utility_fwd.hpp> was introduced with <boost/utility/base_from_member.hpp>
_That_ was the first mistake.
1a. <boost/utility/base_from_member.hpp> #includes <boost/utility_fwd.hpp>, and needs to since a template value default is in the forwarding header.
It should have included boost/utility/base_from_member_fwd.hpp, if anything.
2. The other forward-able items in <boost/utility.hpp> were added to <boost/utility_fwd.hpp> upon first commit.
Unneccessary. boost/utility.hpp is an obsolete construct; it's just there for backward compatibility.
3. The various items in <boost/utility.hpp> were split into several headers.
4. The maintainers of <boost/noncopyable.hpp>, then _and_ now, ignored the fact that <boost/utility_fwd.hpp> referenced boost::noncopyable. This was the mistake.
5. What should have happened was to add "#include <boost/utility_fwd.hpp>" to <boost/noncopyable.hpp> at the time of the split.
Not doing that was the second mistake.
6. The reason for [5]? Headers that have a corresponding forwarding header should always #include that forwarding header. Why? So...
Yes, but noncopyable.hpp shouldn't have a forwarding header.
7. If someone makes a significant change in the primary header, the mismatch in the forwarding header will cause a compile-time error. (If only we caught the mistake at [4], then Dave's change would have been flagged, and we could have avoided this incident.)
8. Unfortunately, Dave and Aleksey didn't understand this and went the other way. Instead of adding "#include <boost/utility_fwd.hpp>" to <boost/noncopyable.hpp> (Bronek Kozicki suggested this), they excised boost::noncopyable from <boost/utility_fwd.hpp>.
So, can we make the change go the other way?
No way, man. Some people already argue against noncopyable on the grounds that it introduces too many dependencies. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com