[EMAIL PROTECTED] (Hartmut Kaiser) writes: > David Abrahams wrote: > >> > As a last resort this certainly helps. And in a year or so >> nobody will >> > talk about the transitional CVS versions. But now it would be very >> > helpful, if there was a separate BOOST_ITERATOR_ADAPTOR_VERSION pp >> > constant, which could be used for this needs (BTW Spirit has such a >> > constant from the early beginnings). Please don't get me >> wrong, I do >> > not want to have a very fine granulated version tracking >> constant. My >> > point is, that such interface breaking changes _must_ be track-able. >> >> Well, here are the problems: >> >> 1. There's no definition of this macro in the current sources >> >> 2. The new iterator adaptors don't use the same file paths, >> e.g. boost/iterator/iterator_adaptor.hpp vs >> boost/iterator_adaptors.hpp. >> >> I'm certainly open to any concrete solutions to this problem. >> Just tell me how to do it. > > Hmmm... You're removed the boost/iterator_adaptors.hpp file > intentionally, right? This makes it even more problematic, because, > there is no chance to circumvent compilation errors.
There are going to be compilation errors anyway, since the interface is drastically different. > What about re-introducing the boost/iterator_adaptors.hpp file: > > #define BOOST_ITERATOR_ADAPTOR_VERSION 0x2000 > #include <boost/iterator/iterator_adaptor.hpp> > > This would allow for some version tracking and a smooth migration path > for those libraries, willing to support both, the new _and_ the old > iterator libs. Thought's? OK, that seems reasonable. Libraries can check to see if BOOST_ITERATOR_ADAPTOR_VERSION is defined and use different code in that case. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
