Re: [boost] boost::iterator_range header surgery

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-11 10:19:30

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