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
> 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?
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
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk