MaximYanchenko skrev:
Hello,
I found that the input/output and comparison functions for iterator_range are inside the header boost/range/iterator_range.hpp.
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.
However, two problems arise here: 1. Backward compatibility. Current programs expect that everything is automatically included. I see two solutions: - Include "boost/range/iterator_range_io.hpp" and "boost/range/iterator_range_comparison.hpp" into "boost/range/iterator_range.hpp" under a define like BOOST_RANGE_1_34_COMPATIBILITY_MODE. This will give the same layout as we have in Boost.Tuple, but I don't want to introduce extra macros if they can be easily avioded. - Make one extra header "boost/range/iterator_range_core.hpp", and have "boost/range/iterator_range.hpp" just including everything. This will the hierarchical layout similar to other libraries like Boost.Spirit. In this case, maybe it worth moving all three new headers to a subdirectory.
The latter approach seems better to me.
2. Again, backward compatibility, but from another point of view. Boost.Range has the unspecified_bool_type() conversion operator. I personally don't see a strong need in it, as it's just a negation of empty(). Also, no standard containers (which are ranges) offer this kind of conversion. So I don't expect wide use of it, and maybe it's worth removing it from the class at all and leave empty() only.
I'm sure it is widely used, and besides, it is there to support a special idiomatic use. So it is not likely yo go away. As for your custom printing, could you not simply avoid to use operator<< altgother (use print()/writeln() or <<=/>>=) ? -Thorsten