Re: [boost] boost::iterator_range header surgery

From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2008-07-14 08:06:34

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