on Thu Jul 10 2008, MaximYanchenko <maximyanchenko-AT-yandex.ru> wrote:
Actually, this causes problems, as I can't provide custom printing and custom comparison: I have my own container printing engine and it worked perfectly well with all standard containers, but failed to compile with iterator_range due to operator<< ambiguity. (Of course, I can just disable instantiation of my printing stuff for iterator_range, but this is definitely not what I want to have.) And, I have no such problems with, say, boost::tuple, as it has separate headers for printing and comparison: #include "boost/tuple/tuple_comparison.hpp" #include "boost/tuple/tuple_io.hpp"
There are also other boost libraries that provide a separate "XXX_io.hpp" header.
So my proposal is: 1. Move operator<< to a separate header "boost/range/iterator_range_io.hpp" 2. Move comparison operators to a separate header "boost/range/iterator_range_comparison.hpp"
This will also serve for boost unification, which is the Right Thing that greatly simplifies usage of any library collection.
Isn't this a bit of an invitation to ODR violations? // TU1 #include "MaximIO.hpp" #include "boost/range/iterator_range.hpp" #include "LibraryThatPrints.hpp" print(some_iterator_range); // TU2 #include "boost/range/iterator_range_io.hpp" #include "boost/range/iterator_range.hpp" #include "LibraryThatPrints.hpp" print(some_iterator_range); If the print template calls different IO functions in these two translation units, that's an ODR violation. Just wondering if there isn't a deeper modularity issue lurking here to be solved. -- Dave Abrahams BoostPro Computing http://www.boostpro.com